4 ms·

This seems like a super edge case or antipattern anyway. I've worked with Node.js for several years and can't think of a time I've patched my local node_modules

by warent 4y ago

This seems like a super edge case or antipattern anyway. I've worked with Node.js for several years and can't think of a time I've patched my local node_modules, because a) how would I ensure they're not overwritten in the next npm install, and b) how would I share those changes with the team

trinovantes 4y ago
patch-package is a tool for this specific purpose https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package You commit your changes as a diff text file and add the patch-package command to your post-install hook so it runs after every install My main use for it is fixing other packages' package.json exports field and Typescript definitions
- warent 4y ago
  Interesting, I can definitely see this being particularly useful for typescript fixes. Where should one put the text files in the code base? Do you create some root level "patch" directory?
  - amaranth 4y ago
    patch-package automatically makes a `patches` directory at the top level of your project with `{package-name}+{package-version}.patch` files in it.
  - jitl 4y ago
    yes
nobleach 4y ago
It's more common than you'd think. Consider the case of an app that consumes a component library. One is building a component in one project, and then consuming it in another project. `npm link` makes this trivial. While I totally prefer building things in isolation, there are often little edge cases that crop up once a library is added to an app. Sometimes it's easier just to consume a lib in a "real world scenario".
fuzzy2 4y ago
One widely-used example is Angular. (It may have changed, I’m not entirely up-to-date.) The Angular Compatibility Compiler (ngcc) creates optimized code of Angular component libraries right next to the original files inside node_modules. It does this automatically as part of the Angular build process. That’s also how I would share any patches: Just apply them when needed during the build process. NPM doesn’t care about what changes inside packages, so you can hack them all you want.
ar-nelson 4y ago
I can think of at least three times I've had to do this, across ~7 years of working with Node. It's an awful hack, but when you need it, you need it.
Sysctl232 4y ago
It's not uncommon but you most likely fork the package then "npm i https://guthub.com/account/forked_package https://guthub.com/account/forked_package" A popular choice if you need some pr's that aren't (going to be) merged.

by warent 4y ago

trinovantes 4y ago

patch-package is a tool for this specific purpose https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package You commit your changes as a diff text file and add the patch-package command to your post-install hook so it runs after every install My main use for it is fixing other packages' package.json exports field and Typescript definitions

warent 4y ago
Interesting, I can definitely see this being particularly useful for typescript fixes. Where should one put the text files in the code base? Do you create some root level "patch" directory?
- amaranth 4y ago
  patch-package automatically makes a `patches` directory at the top level of your project with `{package-name}+{package-version}.patch` files in it.
- jitl 4y ago
  yes

nobleach 4y ago

It's more common than you'd think. Consider the case of an app that consumes a component library. One is building a component in one project, and then consuming it in another project. `npm link` makes this trivial. While I totally prefer building things in isolation, there are often little edge cases that crop up once a library is added to an app. Sometimes it's easier just to consume a lib in a "real world scenario".

fuzzy2 4y ago

One widely-used example is Angular. (It may have changed, I’m not entirely up-to-date.) The Angular Compatibility Compiler (ngcc) creates optimized code of Angular component libraries right next to the original files inside node_modules. It does this automatically as part of the Angular build process. That’s also how I would share any patches: Just apply them when needed during the build process. NPM doesn’t care about what changes inside packages, so you can hack them all you want.

ar-nelson 4y ago

I can think of at least three times I've had to do this, across ~7 years of working with Node. It's an awful hack, but when you need it, you need it.

Sysctl232 4y ago

It's not uncommon but you most likely fork the package then "npm i https://guthub.com/account/forked_package https://guthub.com/account/forked_package" A popular choice if you need some pr's that aren't (going to be) merged.