fix(builtins): move to generated node builtins fixture#157
Conversation
We use template-oss and leverage Dependabot to update the CI to run for new major versions of node, right? Should we aim for that template-oss PR to fail if Node 26 introduces new builtin modules, so no one has to remember to revisit this package? |
|
Other runtimes may need to be a "BYOB" (bring your own builtins) situation where you can pass in other builtins. If we go down that route we may want to export the current ones as an attribute off of this module so you can safely extend it from a well known location. |
Do you base that on #126? I think it's asking for consistent responses across runtimes. Would this BYOB feature be for registries other than npmjs.org? In the case where clients and third-parties use this package, I assume its used to detect early that the registry will reject a publish (currently, or in the near future). |
🤖 I have created a release *beep* *boop* --- ## [7.0.2](v7.0.1...v7.0.2) (2026-01-06) ### Bug Fixes * [`78cc913`](78cc913) [#157](#157) builtins: move to generated node builtins fixture (#157) (@wraithgar) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
validate-npm-package-name can be bundled now npm/validate-npm-package-name#157
This generates the node builtins from runtime instead of using pulling them from the runtime. It will allow this to work in a browser setting with no resolve fallbacks needing to be added.
Current questions with this approach:
How will we know to update this when node 26 comes out?Alternatives:
requirestill but default to an empty array if it's missingCloses #124