Bootstrapping the initiative: TODOs?

[joyeecheung]

A few TODOs come to mind:

1. Starting a team for looking into the package shipping patterns. We'll need to set up contribution guidelines and team onboarding/offloading/consensus seeking. It would be great if we can get maintainers of bundlers and package automation tools involved to discuss and keep folks on the same page about the understanding of these practices.
2. Looking into existing shipping patterns on npm. When I was investigating the module loading patterns of high-impact npm packages, I saw there are many packages out there using patterns that are not documented in the previous package.md. In fact the practices recommended by the previous documentation were considered less preferable in some cases. See Recommend node/default conditions instead of require/import as a solution to the dual package hazard node#52174 which recommends node/default over import/require. We should look into documenting what the community actually does, and if necessary, document discussions about their pros and cons.
3. Discuss the recommended way to ship packages for various kinds of support goals. In particular, for these scenario
   • A package that has been authored in TypeScript/ESM, and has been shipping dual or faux ESM, and wish to ship native ESM for newer versions of Node.js
   • A package that has been authored in CJS, and wish to transition to ESM while maintaining CJS support for older Node.js releases while require(esm) is still experimental.
   • ..more scenarios to come, we should open separate issues to track these, but we'll get more productive after 1 is done.
4. Reaching out to existing high-impact packages that intend to ship native ESM to validate what we document
5. Work with community content creators to spread the word about the recommended patterns and migration practices. Maybe also reach out to some high-impact tutorials/documentations out there to update too, to prevent future users from picking up the obsolete practices from the top search results.

[joyeecheung]

cc @nodejs/tsc @nodejs/loaders for visibility

[joyeecheung]

Planning to discuss it at the collaboration summit session openjs-foundation/summit#422

[mhdawson]

There has been some related discussion in the @nodejs/package-maintenance team so at mentioning team as an FYI

[charlieforward9]

Hello, I attended the early morning session remotely, and I’m currently working on maintaining the react-leaflet-markercluster repository, which was archived for the past two years. One of my initial tasks was to implement ESM support to ensure compatibility with vitest. While I’ve made these adjustments, I’m uncertain if the changes maintain CJS compatibility.

I’m currently reviewing resources on ESM/CJS configuration for Node.js, including this article, to solidify my understanding. Given the small scope of this repository and the few files changed, I’d appreciate a review to confirm my approach. I’m also happy to offer this repo as an example for the broader initiative on shipping patterns.

Here is the PR: yuzhva/react-leaflet-markercluster#214

Thank you!

[joyeecheung]

@charlieforward9 I am not an expert on react but since the PR is using require + import conditions, you might want to give nodejs/node#52174 a read - if the package would be fine to have two instance of itself in the same context and relies on no global state, then it's probably okay. Otherwise it may run into the dual package hazard:

1. Some end user ESM code -> import CJS intermediate dependency -> require CJS version of your package
2. Some end user ESM code -> import ESM intermediate dependency -> import ESM version of your package

now a duplicate pair of the CJS and the ESM version of your package are loaded and initialized in the same context, which may or may not be okay.