Specify supported Node/NPM versions in engines property within package.json

[adamstankiewicz]

Based on the discussion in this PR, we would like to consider adopting the following approach for managing Node.js version compatibility across micro-frontends.

---

Based on the guidance in this article, I believe what the author proposes for maintainers makes sense. We probably should be explicitly defining the supported Node.js version(s) in our repos/libraries with the engines property. I'd be curious to hear your thoughts, not just for this repository, but as a pattern more broadly.

• Define an engines property in the repo/library package.json files that declare the oldest active LTS version of Node.js (i.e., Node 18):

{
  "engines": {
    "node": "^18",
    "npm": "^9"
  }
}

• "When a Node.js version reaches end-of-life, even if your library is finished, bump a major version updating the engines field to the current oldest active LTS of Node.js."
• "Consider throwing a helpful exception if your library is used on an unsupported Node.js version."
• "Consider documenting your version support policy." See example from the aforementioned article.

---

Tasks

Beta Give feedback

1. Create an engines property in all repos/libraries that rely on Node.js/NPM. Include the current oldest active LTS of Node.js and NPM.
2. Create a new (Open edX) wiki page documenting this high-level approach to Node.js version upgrades, irrespective of which Node.js version it is. The page might be titled something like "Node.js Upgrade Lifecycle" and include the above outlined steps.
3. Consider whether it's possible and/or makes sense to throw an exception if the repo/library is used on an unsupported Node.js version.
4. Consider whether READMEs should be updated to include a version support policy similar to the example provided above,.