Hacker News Reader

Comment by JLCarveth | Hacker News Reader

> No node_modules folder by default (use --node-modules-dir for backwards compatibility). Modules are cached once in a special global directory.

This is definitely interesting. It will be nice not having to deal with that massive directory in each project.

View on HN

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

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.

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

It's the same way every package manager has done this since the beginning of time.

Well except for NPM :D

Composer also?

Package managers end goal was the user to use the package, so it was good that they were installed globally. npm goals, as a tool for devs, includes having projects self-contained and not interfere with each other, which is pretty different goal and thus having a local node_modules has multiple advantages instead of installing everything globally. Kinda how docker or virtual machines work, but just for packages.

I was under the impression that Node (and the node_modules folder) predated NPM. So NPM was just going along with the concepts laid down by Node.

Every system package manager. There are plenty of programming dependency managers that don't use a centralised store though.

except for rust which downloads the same package over and over again, even in the same project!

I heavily disagree with the very premise that OS package managers are solving the same problems as language-specific, development targeted dependency management solutions.

Language-specific package managers also often install globally, at least by default.

Really? I know pip does it by default if you don't use virtual envs, but that's related to how pip works - activating the venv basically swaps pip/python executables and `site-packages` to the ones in the venv directory. I admittedly can't think of another I used where that's the case (none of cargo, go mod or npm/yarn/pnpm install globally by default). I admittedly did not really try others enough to notice how they work.

Still, the end-goal is not the same, IMHO. Outside exceptions (e.g. some developers not packaging their applications and making users install through `pip`/`npm install -g`, which I also really dislike), your typical end-user would not interact with language specific package managers. They're most typically used for development/deployment dependencies, not end-user installation.

Go's not technically global but the path of least resistance is to use it as if it is. You'll only notice the difference on an actual multi-user workstation, or if you take extra steps to get a per-project package directory.

Rubygems is usually global.

The granddaddy of them all, CPAN and its cpan install tool, defaults to installing globally, in practice, on most systems.

Pip, as you noted, does it.

I think Maven's typically user-scoped, so not really global, but also not project-scoped like npm. Similar to Go.

You can get around this in most or all cases—sometimes with options or config, sometimes with extra effort or some aliases or scripts, sometimes environment variables, sometimes with 3rd party tools—but the simplest or default mode is global installation, or at least project-global if not user-global in Go's or Maven's cases. And many of those solutions (e.g. rvm) still don't scope installation per-project by default, like npm does.

At the time npm got started, especially, it was definitely an outlier in its default scope. Some others have taken its approach since, and maybe a majority of total language-specific package managers even do, these days, but adjusted for actual use in the wild, I bet NPM's by far the most-used one that operates that way, and that most of the other popular ones scope more broadly—including, often, globally—by default. That is, a language-specific package manager one runs into in the real world, in 2022, usually isn't going to scope packages like NPM does without some extra effort. Global or per-user scoping (the latter being functionally identical on any single-user machine) are more likely.

This sounds similar to PNPM: https://pnpm.io/. You still get a node_modules folder but it just has symlinks into the global cache. Ot was basically a drop-in replacement (minus the need for —shamefully-hoist on our install) and ended up being faster to install and build

Reply on news.ycombinator.com