Thing is, node_modules isn't just thirdparty modules.<p>It's just what the Node path resolution standard uses, which is also how Local Modules (the "/src/node_modules" structure) allows you to import other files with clean paths, without having to add a config in every tool of the toolchain, post-install symlinks, or any other non-crossplatform tricks. It just works because it's literally what Node uses to resolve paths, and all build tools are based on Node, so when you stick to the standard resolution, you can add new tools to the toolchain without needing a bunch of configs for them to find your files. For example, it's now also the default resolution in Typescript as well.<p>The only time /src/node_modules doesn't work is when tool goes out of its way to break it, and wrongly assumes that node_modules can only ever be used for external thirdparty code (e.g. Jest).<p>So best of luck to make Node + NPM + Yarn to agree on a new path resolution syntax, but I hope we won't end up with another tool-specific resolution that only works in Yarn.
I'm the author behind the proposal, feel free to ask me any question you might have!<p>As a personal note, I'm super excited and so grateful to have had the chance to work on this project - node_modules have been a longstanding thorn in the side of the Javascript ecosystem, and to finally have a chance to try something completely new is amazing.
Removing `node_modules` would be fantastic, but not at the expense of native modules:<p>From the PDF:<p>"On the long term we believe that post-install scripts are a problem by
themselves (they still need an install step, and can lead to security issues),
and we would suggest relying less on this feature in the future, possibly
even deprecating it in the long term. While native modules have their
usefulness, WebAssembly is becoming a more and more serious candidate
for a portable bytecode as the months pass."<p>WebAssembly is not "more and more a serious candidate" to replace native modules.<p>The issue with post-install scripts needs a better long-term solution, but simply deprecating native modules is not it.
npm announced crux yesterday, seems focused on the same problems. Approach seems slightly different, although there aren't as much technical details available for crux (unless someone has a better link):<p><a href="https://blog.npmjs.org/post/178027064160/next-generation-package-management" rel="nofollow">https://blog.npmjs.org/post/178027064160/next-generation-pac...</a><p>edit: found the repo, seems a bit behind yarn's effort and not yet beta status. <a href="https://github.com/npm/crux" rel="nofollow">https://github.com/npm/crux</a>
This is effectively how pub, the package manager for Dart works. At version resolution time, we generate a manifest file that contains the local paths to every depended-upon package. Then, at compile/load time, tools just use that file to locate packages.
Very cool, does this mean you can check in the dependency file to version control? Just like yarn.lock?<p>As much as I hate node_modules, there are times when I want to see how a library is implemented. Is there a way to have some libraries in node_modules? Say only the ones in listed in the package.json file
I wish there was something I could do about reducing the contents of the node_modules folder instead of hiding the files somewhere else on disk.<p>It angers me how many dependencies very simple projects amass.
Congratulations to the JavaScript community in reinventing the Maven local repository.<p>Hopefully yarn does a better job at validating dependencies than early Maven 1 and 2 did.
Nice work – what's being done to make this the default behavior in node and deprecate node_modules proper, or is this forever destined to live in the awkward place of userland-but-not-really kind of territory?<p>People have already mentioned native modules. Install scripts are a nuisance, but exist for reasons. If you remove support for them – provided this project takes off, which I suppose it will because bandwagons – you risk people performing install-type tasks on first module load, potentially creating an even worse situation. Has this been considered as a risk?
From what I understand: instead of cp -rf from offline cache, or ln -sf (which doesn't work for a large percentage of packages due to node being node), they propose to use a custom resolver to tap into the cache directly.<p>This will also break for various packages due to fs.readFile* dependencies, gyp, and other things. If your dependency tree is 4k+ node modules, the "vanilla" yarn or npm resolution and reconciliation techniques are already so brittle, that changing them will undoubtedly break things.
Currently I use npm for angular projects. Before writing even hello world , I have to perform npm install on the project and install so many module to serve up small web app. This seems like we are going in the right direction, cant wait to try yarn as package manager.
How does yarn pnp compare to nix? (node2nix)<p>I've been thinking about unifying our current ivy+yarn+bower setup, but haven't yet gotten much past thinking about it...
This is a compelling reason to switch:<p>From <a href="https://pnpm.js.org" rel="nofollow">https://pnpm.js.org</a><p>"Efficient: One version of a package is saved only ever once on a disk. So you save dozens of gigabytes of disk space!"<p>Without digging, I imagine this will be more like Maven's cache.<p>NPM's design decision to flatten the version hierarchy baffled me. And has occasionally tripped me up.
The problem in javascript seems more an ideological one where programmers instantly reach for a package that has multiple dependencies of which those dependencies have even more dependencies.<p>There's this culture of not caring about bloat it seems in the vast majority of javascript projects. left_pad comes to the mind as the poster boy for this stuff.