A shared package that calls process.env takes a dependency on a name in somebody else's deployment. Nothing in the signature says so. The table name is just a string the module hopes to find the first time it runs, inside whichever product loaded it. Uehara's rule inverts the direction: environment-dependent values, table names among them, are injected from the consumer, which is why he names it the design decision that mattered most [10]. The dependency then sits in the call site, the compiler checks it, and two products can name their tables differently without the package learning either name.
That is the same rule as the line he put in the README: the foundation holds no runtime, and the API, admin UI and data live alongside the product [8]. Only reused code goes in the provider; the screens and the actual data-access implementations stay on the consumer side [9]. A package that reads env is carrying a fragment of runtime in with the library, because it assumes a process it does not own.
The migration ledger reads as a real tradeoff, not a clean win. The v1.0.0 move changed about 60 files on the consuming side and let him delete 15 files of block-editor implementation the product had been holding locally [11]. That is four files touched per duplicate file retired [18]. He is explicit that the output of sharing is the disappearance of the duplicated copies rather than any new shared code [12]. The second consumer should come cheaper, but only if the injected-parameter surface does not move for it. If product two needs a value product one never passed, you pay a change on both sides and a release in between.
This is one developer's workspace, written up in his own post [20], and the pieces had been drifting for a while: the utility toolkit dates to August 2024, the block editor to June 2026 [13][16], roughly 22 months apart [19], with no consistency in dependency direction or publish target across them [2]. The file counts transfer if your duplicates are still copies of one implementation. They do not if the copies have forked, because then those 15 deletions are a merge instead. The process.env ban is cheap for him because he owns both sides of the boundary. In a multi-team org the same rule means publishing a config surface, versioning it, and telling callers when a parameter appears.
Option C on his shortlist was to do nothing and keep the local copies, ruled out because block-editor copies were already accumulating on the product side [6]. It was never a real candidate, just the default state that kept running while the decision got made.
What makes the env rule worth copying is that it is checkable by machine. A CI step that greps packages/ for process.env and fails on any hit enforces the boundary without a review conversation. He does not say he wires that up, and his counts are one person's counts, but that check costs the same line of YAML at any headcount. The part that scales with repository count rather than consumer count is the other half of option B: CI and versioning pulled into one place, with everything published as @org/* to GitHub Packages [5].
