Rethinking JavaScript Infrastructure

[cpojer]

Check out the post here: https://cpojer.net/posts/rethinking-javascript-infrastructure

What do you think?

[mindplay-dk]

It doesn’t matter if you are listing the UI library under dependencies or devDependencies

But it does, if you want to be sure packages are compatible - any shared dependencies of your dependencies must all have compatible version constraints. If you ended up bundling two different major versions of the same package, you could get very strange results and/or much larger bundles.

[mindplay-dk]

I'm not sure why the distinction matters?

If I'm building an application with, say, two dependencies that depend on xyz^1 and xyz^2 respectively, and let's say each package exports a class that extends Component from two different versions of that xyz package. I have to choose a version of xyz for my application, and if that package includes a runComponent function, it won't be compatible with components from both of those libraries, since they extend different versions of Component.

Even if the latest version of runComponent happens to be backwards compatible with earlier versions of Component, I will end up bundling two copies of xyz which definitely isn't ideal.

[cpojer]

This point is not about compatible versions which is a separate concern. The point is that when an app is deployed, it needs all the dependencies and devDependencies. Barely any project uses the --production flag to only install production dependencies. Even if people did, dependencies like “react” don’t need to be part of the production deploy because they are compiled into bundles that are deployed. As a result, it doesn’t matter whether people use dependencies or devDependencies.

[mindplay-dk]

In the past, entries in the dependencies field usually meant that code is part of the actual production build artifact, while entries part of devDependencies are only used during development.

It still means that - for example, for tools like snowpack, the distinction still matters even for applications. But, at the very least, it matters in an advisory sense, if you want other contributors to understand at a glance where your dependencies are used.

Even if we check all of our dependencies into source control, I can't see how the distinction is "a mistake" in any way.

[vjpr]

I think @cpojer is correct in the fact that the --production flag is a bit useless now, and for applications it is not really important. The point he makes is to justify that deps and dev deps can be checked into node_modules without any problems - which is true.

The biggest problem I always faced was that you need dev deps to run tests, but then if you deploy with --production, things could break because you didn't test your app with dev deps excluded, and if you misplaced a dep then you've got a production defect. There's ways to work around this but its a little tricky to setup.

It's probably good to have the distinction, but using --production is probably a bad idea.

[mindplay-dk]

None of that means that devDependencies "were a mistake" - they don't serve any hard requirements when it comes to deployment, sure, but they still serve the purpose of versioning during development. (Not sure I'd want to use npm for deployments in the first place - you don't want a third-party server outage to hold up a critical deployment... a simple gzip is probably both safer, faster, simpler, and more atomic.)

[vjpr]

With all of the steps above applied, a repository can be checked out or rebased, and engineers can immediately start developing inside of it.

Maybe there is a simpler approach. I use git worktree + pnpm and it's a pretty great workflow.

Pnpm stores every dep once on disk across multiple repos.

git worktree avoids the node_modules churn when working on or reviewing other branches than the one you are working on.

If your colleagues add/remove some deps, the pnpm install will be pretty quick because it will only have to download the added packages, and will just be creating symlinks and hardlinks to the global store.

This makes checking third-party product code into version control overkill.

Interested in your thoughts on this.