This repository was archived by the owner on Jun 24, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 24, 2026. It is now read-only.
user-land shims for tooling group initiatives #7
Description
One topic discussed in our Node+JS Interactive meeting on tooling, was the introduction of user-land modules to help ecosystem modules take advantage of new functionality (.e.,g, mkdirp) while still falling back to their prior implementation.
I've opened this issue to capture a couple action items around this topic.
Publishing Shims Under Node.js Organization
How do we feel about creating a @node, or @nodejs organization on npmjs.com and using this scope to publish shims under? A first candidate being @nodejs/mkdir-recursive-shim.
- let's figure out who to talk to about doing this, and if we have consensus create the scope on npm and
nodejs/mkdir-recursive-shimrepo on GitHub?
Actually Write @nodejs/mkdir-recursive-shim
- @guybedford you'd offered to take this on? let's check this box when we've done so?
Module.wrap is a candidate for a similar shim
There's a discussion in nodejs/node#21573 about using an improved API for Module.wrap, this would potentially be another good candidate for a shim.
- should the tooling group help create a shim for this?
- if so, let's create a tracking ticket and pitch in on module: use compileFunction over Module.wrap node#21573.
Activity
mhdawson commentedon Oct 23, 2018
There has been some past discussion on whether to have a nodejs npm organization, but this is a bit potentially a bit of a different use case. See nodejs/TSC#211 for the previous discussion.
As the number of modules grows it may be time to rethink our original decision if we can address concerns about modules being namespaced. We would not necessarily have to apply it to all modules either, but it would be good to have a "preferred" approach that is followed unless there are good reasons.
bcoe commentedon Oct 23, 2018
@mhdawson now that LTS supports scopes, I'd advocate starting to use the
@nodejsscope for our modules. This adds an additional signal to users of the module that it can be trusted, as the community learns that the Node.js project owns the scope.I can poke the appropriate folks at npm to make sure this scope is owned by the Node.js project, if this hasn't been taken care of yet.
CC: @nodejs/tsc
lirantal commentedon Oct 23, 2018
I'm chiming in here because we had similar ideas in the Security WG about publishing packages to npm that are affiliated with the work on the WG like say: tooling to validate a security report, or more importantly our vulnerability database as an npm package.
/cc @vdeturckheim
mhdawson commentedon Oct 23, 2018
@bcoe thanks for following up to see if the project owns the scope.
MylesBorins commentedon Oct 23, 2018
we do own the @nodejs scope.. but I'd advice caution about using it for userland modules. There is an on going discussion and effort to put node.js core modules in a namespace and we want to ensure we are not duplicating effort here
nodejs/node#21551
it would be quite confusing to have both core and userland modules in the same namespace imho
bcoe commentedon Oct 23, 2018
@MylesBorins @ljharb it feels like we should have a scope that's used for user-land modules managed by the Node.js project, even if it's not
@nodejs.MylesBorins commentedon Oct 23, 2018
@bcoe +1 on having a scope, just want to make sure it is well... scoped :P
ljharb commentedon Oct 24, 2018
Agreed on a scope. I think it’s best to have a different one for core modules than for userland things.
guybedford commentedon Oct 27, 2018
@bcoe if I remember correctly, I believe I was pushing to backport the mkdir recursive implementation to 8.0 as opposed to the shim route? Would be glad to work on a backport PR if no one can see immediate issues with this.
boneskull commentedon Dec 6, 2018
is node-environment-flags (a polyfill for
process.allowedNodeEnvironmentFlags) something that belongs in thenodejsorg?boneskull commentedon Jan 11, 2019
@iansu and @bcoe were trying to get a shim into package
mkdirpbut it doesn't sound like substack was interested.boneskull commentedon Jan 11, 2019
We seem to be waiting on nodejs/node#21551 to move forward with that, but it doesn't mean we need to wait to publish shims.