[FEATURE] Publish Manifest

[isaacs]

From slack:

darcy
https://x.com/colinhacks/status/1798136783538176048
^ this is pretty interesting. It definitely frustrated me that npm didn't support more fields/usecases with publishConfig. pnpm seems to have broadened the scope (ref. https://pnpm.io/package_json#publishconfig) but still no engines. If engines was added then it would make dev* specific variants unnecessary (because you can define what the package publishes with vs. what the project is using). I recently suggested this in @ljharbs devEngines npm PR npm/cli#7253 (comment)

isaacs
Just googling and searching twitter, looking at colin's assumptions, and the discussion in there, it seems like there's a real user expectation that publishConfig ought to override the package.json fields at publish time, rather than config values at publish time. That's really interesting to me.

it highlights an interesting discrepancy between "package.json as dev config" vs "package.json as dependency package manifest"

when publishing (or installing the package as a dep), you want the "dependency package manifest" view, but when installing locally, you want the "dev config" view

it's obviously way too late to rearchitect the poor thing, but wow, how different history would've been if that'd been considered from the get-go. Like, no need for devDependencies, just put it in the "local dev config" part of the file, and put your dependencies in the "published manifest" part of the file, or something.

oic, yeah, people are assuming that because pnpm does that, lol

Maybe it'd be good for us to come up with some clean reliable vlt-specific way to say "yeah, I know what the package.json says, but at publish time, I want this or that to be merged into the manifest that goes in the tarball/registry"

publishManifest or something? then when we publish and create the tarball, we can throw out extraneous junk that only matters at dev time, and ship a terse flattened manifest? no devDeps, no prettier or eslint or tap fields, etc.

[isaacs]

Just thinking through this, what if we let people put a vlt-publish-package.json (spelling TBD) in their project, side-by-side with package.json? Then, whatever's in that file will be deep-merged into package.json when we pack and publish.

Yes, giving people that level of configurability might be a bit of a foot-gun, for example you could have broken exports or something that you don't catch because it's not what node etc. will be looking at. But I think that's kind of fine. Overriding anything at publish time would have the same issue, even configs (though to a lesser extent), and so far no one has blown off any toes with it as far as I know. If you do get burned, it's an easy enough fix, just publish a new version.

The bigger disadvantage is just feature discovery, but it's kind of rare enough to need it, that people looking for this type of feature go to the docs looking for it. (Though, in the case of publishConfig, they go to the docs, read the docs, and come away with completely the wrong impression, maybe because "config" is overloaded in their mind? Like they think of package.json as a "config file" of sorts? Which, in fairness, I guess it kind of is.)

We don't need to support publishConfig in package.json, because you can just define commands.publish in vlt.json.

Advantages I can see:

• No need to negotiate a new top-level field in package.json with other consumers
• very explicit
• easy to implement
• stays nicely out of the way of any commands that don't care about it (ie, everything except pack and publish)