Today I learned how to get a very old Angular project running locally. Even though it was Angular in this case, the steps are likely to be similar for most aging node based projects. First I had to go to the Version compatibility page for Angular and find the required version of node. In my case it was Angular v7 so I needed Node v10. Next, you’ll want to use a version manager for node. nvm is the most well known but you have to run it in bash on Windows and I find Volta much nicer to use. ...
I recently discovered this handy site that aggregates all usual info I tend to look at when deciding whether or not I want to pull in an NPM package as a dependency. npmpackage.info Some things I tend to look at: When was the last version published? How many sub-dependencies does it have? With the rise in supply chain attacks, newer packages try to minimize these with some advertising zero dependencies How much will it add to bundle size? I usually check Bundlephobia and this displays the stats from there along with everything else How widely used is it?
Today I learned that npm can handle merge conflicts in your package-lock.json file for you. After you resolve any merge conflicts in your package.json, you can just run npm install [--package-lock-only] and npm will resolve the conflicts in the lock file. If --package-lock-only is provided, it will do this without also modifying your local node_modules/. Solving conflicts in package-lock.json
Today I learned that node natively supports import path aliases with the imports field in package.json. The nice thing about this is that they’re supported by most node tools now so you don’t need to configure your aliases separately in different tools like eslint, webpack, vite, etc… If you’re not familiar with import aliases, they’re a handy way to avoid unwieldy relative import paths. instead of: import utils from '../../../../shared/utils'; you can have: import utils from '#shared/utils'; A nice config to start with is something similar to: ...
Today I learned that as of npm cli v8.3.0 (2021-12-09), you can use the overrides field in package.json to “override” nested dependency versions. This is handy for several scenarios, but for me I used for a third-party react component that has a peerDependency on v16 of react even though it works just fine with v18 but it isn’t under active development at the moment so I had to override the version it accepts: ...