The version that wasn't there
A shared package that worked locally and could not have worked in production.
A client site built fine on my machine for weeks. It could not have built on the deploy server, and I didn’t know that until I looked.
The setup: the component library lives in a monorepo, and each client site is
its own repository sitting inside it. Locally, npm links the client to the
package source — so whatever I’ve just edited is what the site uses. On the
deploy server there is no monorepo. There’s one client repo, and npm installs
whatever its package.json asks for from the registry.
That site asked for ^0.1.1. Its homepage imported two components that were
added in 0.5. Every local build resolved them from the workspace copy and
succeeded; the published 0.1.1 didn’t contain them at all.
The failure mode is nasty because the two environments disagree in the direction that hides the problem. Local development is the more permissive one, so the error only ever appears on the deploy, after a push, in front of a client.
What I’ve changed:
- The pin is now a decision, not a default. A site pinned to a range is
deliberately frozen; a site on
*follows the published latest — which means publishing is part of shipping, not something to do afterwards. - Any package change now gets published before the client deploy that needs it. Obvious in hindsight. Less obvious when local builds are green.
- The repository’s notes say which sites are on which pin, because “does this site pick up package changes?” has a different answer per client and I will not remember it.
One more trap, filed here so I stop rediscovering it: npm install does not
always replace an existing node_modules/@iceniweb/ui. If a site behaves like an
old version after an upgrade, delete the folder and install again before
believing anything else.