Collab with the PM WG?

[wesleytodd]

I have not been closely following the conversation here (maybe that was a mistake for me), but it means I missed the transition out of experimental (not a cli flag anymore). I was wondering if there was something the Package Maintenance WG could do to help ease the transition for module authors? Based on feedback I heard (thanks @tbranyen), this might be a painful process for many module authors and app maintainers. If there are documentation pieces we can help with, or tooling we could build to help, it would be great to collaborate. Does this sounds good to you? If so, what would next steps be?

[GeoffreyBooth]

Well for starters, you should probably read the new docs sections on packages for ES modules:

• https://github.com/nodejs/node/blob/master/doc/api/esm.md#packages
• https://github.com/nodejs/node/blob/master/doc/api/esm.md#dual-commonjses-module-packages

Helping package authors navigate that would be most appreciated 😄

[jkrems]

Hey - this sounds like a great idea, thanks for reaching out! Trying to remember the kinds of things we had discussed in the past. In my own perceived order of usefulness:

1. yarn init / npm init supporting the generation of "ES module first" packages.
2. Having kind of template for a simple project that wants to ship ESM but also support CJS consumers.
3. Something to generate exports based on root-level files (?). E.g. if somebody has foo.js in the project root, generate { "exports": { "./foo": "./foo.js" } }, possible even skipping foo.js if it just re-exports another file.

[ljharb]

It'd also be amazing if npm publish could check, for any non-x.0.0 version, if exports exists when it didn't in the previous one, and warn/prompt to confirm - but that might be a tall order to ask for :-)

[GeoffreyBooth]

We also wanted to encourage all packages to start including the package.json "type" field, even for "type": "commonjs" (the default if "type" is unspecified). It would be nice if this could be added automatically, or the user prompted to add it, at some point in the init or publish (or install?) process.

[evanplaice]

Explicit pkg.type will be cool

The real issue will come w/ pre-ESM Node incorrectly assuming pkg.main contains a CommonJS module in packages w/ type:module specified.

[ljharb]

@evanplaice that's fixed by using "exports": { ".": "esm.js" }, "main": "cjs.cjs" - and omitting the main if you don't have a cjs entry point.

[wesleytodd]

Ok, so far this sounds like the todo list:

• Work with npm & yarn to get type into init
• Scaffolding tool for a best practice package with exports and dual cjs/esm
• Work with prolific authors and important package ecosystems to roll out changes

Sound good?

---

yarn init / npm init supporting the generation of "ES module first" packages.

We also wanted to encourage all packages to start including the package.json "type" field

So I know this is not the best answer as it is just a tool I maintain, but I added type to my pacakge.json scaffolding tool and plan to add exports generation next. https://github.com/wesleytodd/create-package-json/

I had intended for https://github.com/pkgjs/create to be a scaffold with the recommendations from the different node working groups. What I have there today is more of a library for other scaffolding tools, but I plan on moving that out and replacing it with the scaffold tool for packages. The idea is that npm init is really a basic tool, but in my experience you need something a bit more robust. This is that more robust tool. On the PM WG we have discussed using that Org as a place to house our tooling, if that sounds reasonable to you as well maybe we can collaborate on what goes into that scaffold tool?

[guybedford]

@wesleytodd thanks for suggesting a path here, that would be huge. I'm not sure we necessarily should have an official scaffolding tool for Node.js, but working with npm and Yarn to get a good init experience for ES modules is definitely an important priority. Ideally we would include "exports" support in such an init workflow as well.

[wesleytodd]

I'm not sure we necessarily should have an official scaffolding tool for Node.js

That is stronger wording than I would put it. I think having an example by which package maintainers can use as an example (and if it works for them, a starting point) for their modules, is a good thing. I in no way see this effort as an "official scaffolding tool". The problem is that most people don't care enough to follow along, so just providing guidance is often not enough, a tool which helps them follow guidance is much more effective.

working with npm and Yarn to get a good init experience for ES modules

This is for sure the priority! I followed with a separator because I wanted to be clear that was a secondary priority. I have just maintained too many module ecosystems to want to re-live the "here is a good way" without also providing a tool to make it easy for people who have little or no opinions to easily follow. npm init should not be that opinionated I think, so that is the gap this tool is intended to fit.