3 ms·

Downside is you can't use patch-package Even the --node-module-dir flag just creates a symlink to your home directory cache so you can't do per-project package

• 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.
• dsherret 4y ago
  No, the --node-modules-dir flag doesn't create a symlink to the home directory cache. It creates a copy in the node_modules folder (in the future it will use hardlinks to reduce space, there is an open issue). It's stored at node_modules/.deno/<package-name>@<version>/node_modules/<package-name> (that flag is heavily influenced by pnpm) You can do a patch package by doing something like the following (and then you can move this into a `deno task` https://deno.land/manual@v1.28.0/tools/task_runner https://deno.land/manual@v1.28.0/tools/task_runner when launching your app to ensure it happens): deno cache --node-modules-dir main.ts deno run --allow-read=. --allow-write=. scripts/your_patch_script.ts deno run --node-modules-dir main.ts