Search for a command to run...
As a Senior Principal Engineer at CVSHealth, I specialize in building and optimizing cvs.com to deliver a superior guest experience. Using the latest web technologies, my team and I work diligently to create a user-friendly and intuitive platform that exceeds expectations.
No comments yet. Be the first to comment.
Use the following script to download videos from YouTube using yt-dlp. Incorporating cookies-from-browser can assist in downloading videos that are behind a paywall, provided you have already paid for that content. Please ensure you adhere to the con...
I ran into an issue recently where my autocomplete suggestions on VSCode would only bring up Emmet suggestions and none of the type information would be suggested in autocomplete. After digging through VSCode settings for a bit, figured out that you ...
I recently set up an Nx monorepo with a lot of sensible defaults. My linting config was working perfect in CI. Running ESLint on terminal through Nx would work fine as well but I was not seeing any ESLint issues on my VSCode editor. On digging deeper...
Intro Setting up a NextJS project is exciting, but securing the localhost environment for testing and development can be challenging. To enable a common usecase of accessing cookies from the production domain (e.g., example.com) while working locally...
This will be a running list of things that I found useful while working on enterprise projects. These can be good tips for other projects too but since there are usually a lot of developers working across enterprise codebases, it is a good idea to establish and enforce some Github (GH) practices in a timely fashion (when new repositories are created).
Find more info here. This basically means using a main branch for all development work. Doing this helps you move your code fast to production.
The alternative is something like Gitflow which is a pain to work since you usually have to keep multiple branches in sync with this.
To achieve true trunk-based development, developers should have the necessary tools to fully test each PR in an integration environment. This can be achieved with a preview environment per PR. You might be familiar with how Vercel does this per PR but otherwise, your company might need to set up some in-house infra to provide this support.
mainEnable branch protection to ensure developers follow proper processes before merging code to main. This also ensures devs cannot directly push commits to main, unless you want that for certain developers, which is generally a bad idea. Any changes should go through a PR.
See Github docs on how to set this up.
Squash and merge only for all GH reposGithub provides 3 different options to merge:
On larger projects, where you have a lot of developers working on a common repo, using any of these other options generally means you'll have a bunch of commits on main branch that don't make sense. I know some projects/developers tend to argue that each commit should be a semantic commit, sometimes this just adds too much pain for devs and hinders the ability to move fast.
Since developers should generally be advised to make smaller commits for quicker prototypes and better developer experience (DX), a PR with 50+ commits shouldn't land on the main branch the same way. With Squash merging, you only create 1 commit for 1 PR on main.
This is super valuable when you have a production issue and you have no idea where it came from and you have to now git bisect to find the root cause. With squash merges, you can pinpoint which PR introduced a bug much quicker!
Prefer to use conventional commits on any commits to main branch. This extra piece of information on every commit can be super valuable if your repo is publishing packages to npm/Artifactory and you want to automate bumping major/minor/patch versions of packages. But even on a feature repo with web applications, this provides a nice overview of main branch commits indicating features, bug fixes, chores, etc.
Since you now have only squash merge enabled, you can enable every PR title to have the conventional commit prefix with a Github action PR check.
Create this file as a guide to provide newcomers with onboarding documentation. If you would rather have a common Onboarding document for a larger group with something like Docusaurus, link to that site from this file.
When working in a polyrepo setup with multiple teams owning different repos, having a smaller GH team is nice since you can easily identify ownership. If you have a group of 100 people owning a functionality, it usually means no one owns it. A smaller group, who can be held accountable for an area, is better for quicker feedback cycles.
Add this GH team to the CODEOWNERS file to ensure any PR creations on the GH repo would need the code owner group approvals.
In larger projects, keeping dependencies up to date is critical in the long term. Renovate makes this easy by creating PRs for you. It comes with a lot of baked-in defaults as well to make your life easy. For example, dependencies next and eslint-config-next should be upgraded together in NextJS projects. Hence Renovate creates a single PR for both of these updates and makes the necessary lock file updates for you. It also supports pnpm which is my go-to package manager for all new projects. Check their docs [here](https://docs.renovatebot.com/).
Create PR checks for build, lint, test, format, typecheck etc. to make sure any commits going into the main branch are safe. Also, GitHub lets you mark these PR checks as Required so that developers cannot merge their PRs until these checks pass. You can find this under the branch protection setting for main
