user-land shims for tooling group initiatives

[bcoe]

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-shim repo 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.

@nodejs/tooling (CC: @mhdawson, @dshaw, @jdalton)

[mhdawson]

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]

@mhdawson now that LTS supports scopes, I'd advocate starting to use the @nodejs scope 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]

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]

@bcoe thanks for following up to see if the project owns the scope.

[MylesBorins]

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]

@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]

@bcoe +1 on having a scope, just want to make sure it is well... scoped :P

[ljharb]

Agreed on a scope. I think it’s best to have a different one for core modules than for userland things.

[guybedford]

@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]

is node-environment-flags (a polyfill for process.allowedNodeEnvironmentFlags) something that belongs in the nodejs org?

[boneskull]

@iansu and @bcoe were trying to get a shim into package mkdirp but it doesn't sound like substack was interested.

[boneskull]

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.