nodejs / nodejs/package-maintenance

Update `node` namespace values in package support

Open
#517 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
No language data
Stars
423
Forks
147
PR merge metrics
No merged PRs in 30d

Description

Hey!

For a project, I was trying to implement the node namespace values. I took some notes as I was exploring it, which you can find raw here. However, I'd like to refine them and share my issues/concerns with the node namespace values:

  • Currently, there is inconsistency in how the values are named.
    • lts is equivalent to lts_all if we're looking at the naming of both all and lts_latest/lts_active. We have two naming schemes side by side - effectively, we've implemented both a flat structure and a tiered structure, and the intersection of those two is messy.
  • active is particularly problematic since it co-opts existing terminology.
    • Active is terminology already adopted by the release working group for LTS releases. active in the context of this includes both (Release WG terminology) current and active LTS, which does not help clarify the already confusing state that we exist within.
  • Certain matrix combinations are missing.
    • Example: there's not a way for someone to say they only support maintenance LTS.
    • Example: there's not a way for someone to say they only support EOL versions.
    • While these examples may not be something we'd immediately consider as valid options, there are potentially scenarios where they'd be useful. For example, imagine a polyfill library that backfills all possible new Node.js features to maintenance mode LTS, or a package that intentionally logs a message on EOL verisons.

Rather than building out an incomplete structure (especially when we've collectively consistently struggled with naming release concepts in the past!) as a matrix, I'd like to propose that we simply take the elements of the matrix and directly support those as an array rather than a string.

  • current
  • lts/latest (alternate: lts-latest)
  • lts/active (alternate: lts-active)
  • lts/maintenance ((alternate: lts-maintenance)
  • eol

any combination of these achieves every option in the existing namespace:

  • all: current, lts/active, lts/maintenance, eol
  • lts: lts/active, lts/maintenance
  • lts_latest: lts/latest
  • supported: current, lts/active, lts/maintenance
  • current: current

additionally, some combinations not currently covered by the existing namespace are covered:

  • ones people might actually use:
    • lts/maintenance
    • eol
  • handful of others, but I can't imagine people using them.

the only variation from the Release WG definition of release lines is lts/latest which is a subset that's independent of categories, rather than a combination of multiple categories.

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.

Research direction

Start by reading the existing node namespace implementation and the raw notes in the linked gist; the issue does not name a file or test. Review the project discussion to confirm the accepted naming and array shape, with completion requiring the agreed categories and combinations to be represented consistently.

Written by the indexing model from the issue text.

Assessment

Tech stack
nodejs
Domain
developer-experience
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.