Hacker News Reader

Comment by trinovantes | Hacker News Reader

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 fixes (besides forking and rehosting the package)

I'm also not sure how/if it supports packages that require compiling binaries like sqlite or playwright without post-install hooks

View on HN

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

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

patch-package is a tool for this specific purpose

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

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?

patch-package automatically makes a `patches` directory at the top level of your project with `{package-name}+{package-version}.patch` files in it.

yes

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

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.

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.

It's not uncommon but you most likely fork the package then "npm i https://guthub.com/account/forked_package"

A popular choice if you need some pr's that aren't (going to be) merged.

Reply on news.ycombinator.com