[policy, no patch] Publishing / Maintaining JS libraries produced by Drupal that do not have a dependency on Drupal

Problem/Motivation

There is no way to easily manage frontend libraries that are related to Drupal but not dependent on Drupal, such as the new vanilajs once, the jQuery UI fork, or all the work that is coming from the js-menu-component initiative.

The best we have today is the jquery-once library maintained by RobLoach on Github:

• It's made for Drupal by Drupal folks, but doesn't need Drupal to be useful
• It is well maintained, and kept up to date when necessary
• The npm package only ship necessary files (no test files, github-specific files, etc.)
• There is exhaustive test coverage
• There is documentation shipped with the code
• It is published to NPM, and various cdns
• There is a typescript type declaration (nice for IDE integration)
• There are commands to build the code, docs, test
• Tests are run with Github actions so testsuite can be launched before merging a PR
• The resulting file is actually minified (the generated core JS is not minified today)
• The release cycle is not tied to Drupal's

And while it's pretty extensive and RobLoach has been in the community for a long time, because of the way we integrate with the jquery-once lib, Third party library risks applies: maintainer availability, security fixes, release schedule, etc.

Proposed resolution

Create an official space in github to "host" JS libraries produced by Drupal that does not have a strong dependency on Drupal. Essentially creating a space for "second party" code that is loosely coupled to the Drupal community:

• Project/code overseen by Drupal maintainers
• people contributing have to follow the Drupal community guidelines
• Follows a set of requirements (essentially the JS gates). I'd start with:
  • GPL and/or MIT code (to be defined)
  • There must be a comprehensive test suite
  • Code in all Drupal supported browsers (can rely on polyfill but don't ship with them)
  • If there is a UI, it must be accessible (for an agreed upon definition of accessible)
  • Documentation must be exhaustive and up to date (in code, probably generated from jsdoc, not on a wiki page in github)
  • Require a few commands to be defined and working: build, docs, test regardless of what is used to perform those actions
  • Drupal maintainers/committers are the only ones that can push new releases to npm
  • (a bonus: some metadata that makes generating the Drupal libraries files easier)

The expectation is that a project manages it's own lifecycle and tooling, the "contract" is to ship quality code ready to use. For example a project can choose the testing framework that fits with the library, issue queue, the labels, tags, and everything else that is relevant. Drupal then uses the result as an external library within the core codebase.

Benefits

• Much easier to contribute to libraries. No "drupal" overhead, just the standard github experience
• Almost all JS tooling assumes code is hosted on github, easier to use existing tooling without drupal specific tweaks
• This would solve several problems related to JS library testing that we have currently. Nightwatch or the JS test methods we have today are not well suited for standalone libraries.
• Github is where most JS developers already are, more people to find and fix JS bugs
• Release cycle of libraries are not tied to Drupal release cycle, JS in general moves faster than core (for better or worst), making those packages (possibly) more useful to client projects outside of core
• There is less of a need to audit development dependencies (within reason of course), core will only make use of the generated result so security issues in the testing framework will not impact core for example.
• Almost a detail: we would ship with more minified code

Questions/risks

• Create a "parallel" community and fragment maintenance: True in part, today we don't have a strong JS community in core, we tried for years to get more interest but it's just not happening with the current situation. JS folks will just not comme to drupal.org create an account and read how to make a patch, merge request, find things in our issue queue to fix a bug.
• We will have many different tools to do one thing (different test tools, build pacages): will be necessary for some libs, not enforcing a tool doesn't mean we can's suggest one "by default"
• Credit system is less good on github: while it's true, it is not worst than on other github
• Depend on github infrastructure: we can set up a mirror from github to d.o projects and manage the npm part from drupal.org so that if github goes down, we can still push new code.
• Security coverage: level of integration to existing security process to be defined
• Community moderation: level of integration to the existing CWG to be discussed (how to deal with people breaking community guidelines within the github projects, etc.) might be a big one to figure out, more exposure => more people

Remaining tasks

2. once →
4. Agree upon the recommendations made above and canonicalize them here: https://www.drupal.org/about/core/policies →

Changes

Ideally we'll find a way to require third party libraries with yarn/npm within core to make updating them easier, and generate the libraries definitions for second/third party libraries automatically.

Release notes snippet