yt-dlp --cookies-from-browser chrome --remote-components ejs:github --js-runtimes -f "YouTube_URL" --download-sections "*10:32:01-10:54:45"

On digging deeper, turns out we need to manually specify the working directories within an Nx monorepo correctly for VSCode to pick up the changes. This is as of Oct 12, 2023.

If you run into a similar issue, the first thing to check would be to

• hit Cmd+shift+p

• Type ESLint: show output channel and click that option

and make sure you don't see any errors on the terminal that pops up. In my case, the ESLint output channel was complaining about a missing node module within the ESLint flat config. Adding the dependency got rid of that issue.

The next step was to make VSCode aware of the Nx monorepo setup. This can be fixed by opening your VSCode settings.json file. If you're working in a team and need to ensure everyone gets the setup that you do, you can

• create .vscode/settings.json file in your Nx monorepo

• Add the following config to list each app/package within your monorepo.

{
  "eslint.workingDirectories": [
    { "pattern": "./apps/*/" }, 
    { "pattern": "./packages/*/" }
  ]
}

Find docs here - https://github.com/microsoft/vscode-eslint#settings-options

After making this change,

• hit Cmd+shift+p

• Type ESLint: Restart ESLint server and click that option.

That's it! Your Nx monorepos app and package level warnings/errors should now show up within VSCode as you open files. Happy coding!

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, a specific domain setup like localhost.example.com is needed. This integration streamlines development and ensures seamless functionality within a secure localhost environment.

To be honest, there's nothing other than 1 specific step in this article that talks about configuring things for NextJS projects. So the steps should be widely applicable to other projects as well.

Caddy server is a powerful, enterprise-ready open source web server with automatic HTTPS support. Let's see how we can use this to make your localhost experience better.

Steps

This article assumes

• you're on a Mac. So you might have to find the necessary alternatives for certain aspects in other operating systems.

• you're setting up a local environment for www.example.com. Replace this with your domain name.

• you're setting up a mapping to a NextJS web application that's running on port 3000.

First off, you'll need to map localhost.example.com to localhost . Run

sudo vim /etc/hosts

and add the mapping to the end of this file. A sample here but remember to replace the name with your domain:

127.0.0.1    localhost.example.com

Assuming your app runs on port 3000, create Caddyfile in your home directory (vim ~/Caddyfile) with the following contents again replacing your name :

localhost.example.com {
    tls internal

    reverse_proxy / localhost:3000
    reverse_proxy /_next/* localhost:3000
}

• The first line specifying tls internal ensures Caddy server doesn't go to the public internet to get certificates. Even though you might own this domain in this case, we're doing internal TLS to generate a certificate locally. This helps especially in an enterprise environment where you may not have control over the domain but still want to do localhost development on a project.

• reverse_proxy / localhost:3000 - This ensures the home page path maps to localhost:3000. Notice we don't specify * here as that would stop us from mapping more paths for other sites.

• reverse_proxy /_next/* localhost:3000 - This line is specific to a NextJS project. NextJS serves its assets locally under _next folder. So by mapping all assets under this path to localhost:3000, we ensure things work as expected.

caddy start --config ~/Caddyfile

You'll see the following popup on MacOS to allow Caddy to provision a certificate in your operating system.

Provide the password and hit Update Settings.

Go to your browser and hit https://localhost.example.com now! You should see your local site now has a HTTPS certificate and is able to get cookies from your production domain as expected!

Next steps

You can now use additional reverse_proxy directives in your Caddyfile to configure additional sites. For example, use the following config to add a new NextJS fancy-next-app project mapping.

localhost.example.com {
    tls internal

    reverse_proxy / localhost:3000
    reverse_proxy /_next/* localhost:3000

    reverse_proxy /fancy-new-app localhost:3001
    reverse_proxy /fancy-new-app/_next/* localhost:3001
}

Logging

If you want to debug any Caddy requests that are not being served correctly, you can use the log block in your Caddyfile:

localhost.example.com {
    ...
    log {
        output stdout
        level DEBUG
    }
}

Reload Caddy config

You can decide to have these Caddyfile configs configured per Github repo. In such cases, you might want to reload Caddy configs when switching repos. You can use the following command to do that:

caddy reload --config ./Caddyfile # --config is optional if the current directory has a Caddyfile

Stop Caddy

You can stop Caddy server with the following command:

caddy stop

Conclusion

These steps should get you set up for a smoother web development experience on your next project. So, don't overlook the importance of configuring a secure localhost setup and maximizing the potential of your NextJS project. Happy coding!

Use Trunk based development

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.

Set up branch protection for main

Enable 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.

Enable Squash and merge only for all GH repos

Github 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!

Enable semantic PR checks

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.

Have a CONTRIBUTING.md file for your repos

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.

Create smaller GH teams and make them CODEOWNERS

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.

Use Renovate to automate dependency upgrades

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/).

Enforce PR checks

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

One example that this can be really handy for is modifying commit details.

git rebase HEAD~2 --exec "git commit --amend --no-edit --author='FirstName LastName <author@gmail.com>'"

The above commit modifies the author details on the last 2 commits in the current branch. --no-edit flag ensures this gets executed right away without showing the edit prompt for each commit.

This can be followed up with a force push git push -f on the current branch to modify remote commits.

Recently, I ran into an issue when I just wanted to test a simple script file and wanted to debug it as I wrote it. I could of course use the Chrome debugger but this needed some more work 🤷‍♂

Anyways, I didn’t want to do this over and over again and wanted to set this up in a way that it works across projects on my system.

Here is how I did it:

• Press Cmd + , (or Ctrl + , for Windows) to get into the Settings page

• Search for Global debug launch configuration

• Click on Edit in settings.json

• Add the following configuration under launch

"launch": {
    "inputs": [],
    "configurations": [
      {
          "type": "node",
          "request": "launch",
          "name": "Launch Current Opened File",
          "program": "${file}"
      }
    ],
    "compounds": []
  }

And you’re all set !

Go back to your JS file and hit F5 . Any breakpoints will let you debug variables from here on.

Enjoy debugging 👋

React has made it easy for web developers to quickly develop and deploy apps into production. However, as the app gets huge and you have many developers working on the same codebase, different patterns emerge. And as a result of this, slowly you will end up having performance issues on the website. These may not be immediately visible on the high-end laptops that we as web developers have the privilege to work on. But as the product grows its outreach into newer markets, and your users start using your web app with handheld devices, any performance issue can become a significant problem to the business revenue.

While trying to identify performance issues on my website, I often have to switch between Performance panel on Chrome DevTools and the React DevTools profiler. Once I identify the component having a perf issue with these previous tools, I often have to find out which props actually changed and the previous v/s new value of the culprit prop.

Here is one handy script that you can plug into your componentDidUpdate to identify the props causing re-renders for a particular component.

In the above code sandbox, click on the button to update the component state, and inspect the changing values on console.

Loading images on the web has always been a hot topic. If a user doesn’t see all your images, it doesn’t make sense to send down the wire all those extra bytes. All the techniques used to lazy load images in the past have used a combination of the browser provided APIs like getBoundingClientReact together with event listeners on each image to get the position of the element with respect to the viewport.

The problem with these approaches is the computations involved in the API is heavy and often results in users experiencing scroll janks navigating the site. With IntersectionObserver, all this would hopefully go away!

Solution

IntersectionObserver is an API baked right into your browser to help you combat the problem above.

Code

Check out the following Codepen for a demo on Intersection observer to lazy load images on a site:

The IntersectionObserver API accepts 2 arguments, a callback function and an options object. Checkout the MDN link to see the values for each of these options. Below is a brief one liner for what each options does.

root - The parent element with respect to which the intersection will be calculated. Defaults to null which means, the viewport.

rootMargin - Values specified here will add margin to the root element (specified by root) on all 4 sides.

threshold - Specifies what percentage of the target element (the element being observed) crosses the intersection for the callback to be fired.

Future possibilities

Instead of having an event listener on each and every image, we could have implemented this by having a placeholder ‘div’ in between a set of say, 10 images to load 10 images at once. We could then observe this placeholder instead to minimize the observers on our page and load images (in sets of 10) more effectively.

This would be great for a shopping site where you have a infinite scroll for images.

For those interested to explore more, here is a great article by Surma and Robert Flack on optimizing infinite scrolling:

https://developers.google.com/web/updates/2016/07/infinite-scroller

Conclusion

Intersection Observers are great and here to stay. You could feature detect the availability and go through loading all the images or lazy loading for your users. Check the following link for the available browser support.

https://caniuse.com/#search=intersectionobserver

Helpful links: Intersection Observer API The Intersection Observer API provides a way to asynchronously observe changes in the intersection of a target element…developer.mozilla.org

function isInViewport(element) {
  var rect = element.getBoundingClientRect();
  var html = document.documentElement;
  if (
    rect.top >= 0 &&
    rect.left >= 0 &&
    rect.bottom <= (window.innerHeight || html.clientHeight) &&
    rect.right <= (window.innerWidth || html.clientWidth)
  ) {
    return true;
  } else {
    return false;
  }
}

We will not be going into the details a lot as it will only confuse the beginners and you will be provided with a set of links towards the end of this where you can get more information. Let’s get started.

Fig. below show the basic workflow of Git.

• Git, as in any other Version Control Systems (VCS), operates in 2 regions, one is the central repository and the other region is the one which is local to each user(who clones the repository).

• In the local repository, again there are 3 layers.

• Working directory — This the your working directory where you will be editing the files.

• Staging area — Once you are done editing the files in the working directory, choose the files which you want to commit. These files can then be ADDed to the staging area.

• Committed region — The staged files can now be COMMITted into the committed region. This contains all your commits. Remember, till this point, all the changes are still in your local system.

• Finally, you can ‘PUSH’ all the changes from the local repository to the central repository.

Please follow the below steps to get a hang of GIT in general. This assumes that you have an active BitBucket account.

• Go to your Windows command prompt or the Linux/Mac terminal. In Windows, you can use ‘Git bash’ for easy operation.

• Switch into the directory, where you want your repository to reside.

• Type the commands as shown in the screenshot below :

• ‘git config’ allows to define configurations for your git repositories. Here we define the user name (<first_name last_name>) and user email address which will be used by GIT for all commits that you do.

• If you wish to use a different email address only for specific commits or for specific repositories, you can provide the ‘git config’ command inside the specific repository folder and omit the ‘ — global’ flag.

• Eg: $ git config user.name “Adarsh Konchady”

• Eg: $ git config user.email “akonchady@gmail.com”

• Next create a GIT repo and switch into it as follows :

• Here, we first create an empty Git repository using ‘git init <repository_name>’ and then switch into it.

• ‘git status’ gives you the status of the current working directory and the staging area. Please refer the first slide of this post again in case you have difficulties remembering the staging area :)

• Let’s now create a file and add some lines into it. We will be using the default vim editor to do this. If you are not familiar with the ‘vim’ editor, you can go through this link for VIM editor commands.

• Type ‘vim index.html’

• Press ‘i’(insert) and start typing the contents.

• Once done, key in Escape -> :wq

• This will save the contents and return back to the prompt

• To verify if file was successfully saved and view its contents, type

• cat index.html

• Now, check the status again by typing ‘git status’. You will see something as follows :

• As you can see, the newly created file ‘index.html’ is shown in red color. This means your changes are still in the working directory.

• Let’s add this file to the staging area now.

• Type ‘git add index.html’

• Note, to add all untracked/modified files in the current directory recursively, you can type ‘git add .’. The period(.) indicates the current directory.

• Now, type ‘git status’ again. You will see the file in ‘green’ color as follows :

• Now that we are ready to commit our changes, let’s do it !

• Type ‘git commit -m “My first commit”

• Please note that it is mandatory to add a commit message while committing your changes. This is because when someone views your commits later on in the project cycle, he/she can actually pinpoint when a specific feature was pushed in and with which commit.

• After you do this, press ‘git status’ again. You won’t see file names !! Surprising ???

• As mentioned earlier, ‘git status’ will only give you the status of the ‘working directory’ and the ‘staging area’.

• If you want to see the changes of the committed region, type

• git log

• If you only want a short commit has code and the message, you can also type

• git log — oneline

• At this stage, we are done with all that has to be done in the local repository. It’s time to push your changes into the central repository so that others can see your changes!!!

• To do this, follow the following steps:

• Create the repository, viz. ‘mySampleRepo’.

• Once the repository is created, click on the ‘Clone’ link on the left panel.

• Copy the URL for HTTPS dropdown.

• Come back to the command prompt/terminal and type the following commands :

• git remote add origin ‘<url_copied_from_your_bitbucket_account>’

• This will create a pointer ‘origin’ in your local repository which, from this point onwards, will be pointing to the central repository.

• A ‘remote’ refers to a remote version of your repository.

• git push -u origin — all

• This will push all your local changes to the central repository

Congrats ! You are done with all the steps ! Enjoy !

Stay tuned for the next tutorial on branching and rebasing in Git.

Helpful Links

• Atlassian Git tutorial — https://www.atlassian.com/git/tutorials

• This is a quick guide to the git commands.

• Gitolite — http://gitolite.com/gcs.html#(1))

• This provides a clean graph representation of all the Git commands.

• Git SCM book — http://git-scm.com/book/en/v2

• If you really want to master Git, complete this book !!!