Post

Geoff Goodman
@goodman.dev

The very need for this makes me think it is evidence or a larger disconnect: package.json tries to encode metadata for three very distinct and sometimes mutually exclusive use-cases: 1. Developing the library / service / app 2. Consuming the library 3. Running the service / app

Lars@webpro.nl

✂️ What goes into dependencies vs devDependencies? Anyone wrote the go-to article? Could image there's like only a few clear strategies most projects could agree on. Jotted down this reply, but would be great to be able to link to something less scrappy/informal. → github.com/webpro-nl/kn...

0 reposts1 like

Geoff Goodman
@goodman.dev

Overloading package.json with these different jobs-to-be-done is the sort of thing that leads to these other sub-optimal outcomes: 1. Massive docker images that include dev deps. 2. Inclusion of unwanted, inert files in `node_modules`. 3. Credential leaks meant only for dev that get co-opted in.

Geoff Goodman
@goodman.dev

I have often wondered how to fix this and I'm not quite sure what strikes the right balance of trade-offs. But I think an workflow wherein the dev-time and prod-time metadata is isolated in different files is a good starting point.

Geoff Goodman
@goodman.dev

In a library with a build step, I'd love to see package.json be a generated file in ./dist, for example. With no build step, I imagine the shipped package.json being in a sub-directory that represents the to-be-shipped files of the larger project. Maybe workspaces already offer tooling for this?

Geoff Goodman
@goodman.dev

Does this resonate with you? This is me trying to look at this through a systems lens, "What is the system at work that creates the need for this complexity?" I hope to start brainstorming by proposing some ideas but I'm in no way pretending that they're the *best* ideas. How would you tweak it?