Bootstrapping the initiative: TODOs?

Open
#2 8 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Documentation
Clarity
Needs clarification
Activity status
Stale
Domain
documentation

Research direction

Start by reviewing the previous package.md documentation, the high-impact npm package research, and the linked Node.js discussion. Define the separate package-shipping scenarios and the community research needed before documenting recommendations. Done means the initiative has clear contribution and validation steps plus agreed documentation topics.

Written by the indexing model from the issue text.

Description

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 https://github.com/nodejs/node/issues/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.
Dominant language
JavaScript
Stars
87
Forks
11
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nodejs/package-examples

All issues in nodejs/package-examples

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.