Split off some parts of coreutils

[vidartf]

In concert with the major version release of coreutils, we should consider splitting off some parts of the package into new ones.

Pros:

• Avoid API breaking changes of one part causing consumers of other parts to need to update their dependency/code (or having to add a X || Y semver dependency).
• We are already moving polling out (to Lumino, see Port coreutils#Poll to Lumino #7598) so now is probably the best time to move other parts as well.

Cons:

• More packages to manage.
• More lines of code to change for people updating extensions to lab 2.0.

What to split off

The current exported symbols of coreutils are:

• ActivityMonitor
• DataConnector / IDataConnector
• Debouncer (being moved to Lumino)
• DefaultSchemaValidator / ISchemaValidator
• IChangedArgs (pure typings)
• MarkdownCodeBlocks
• nbformat
• PageConfig
• PathExt
• Poll / IPoll (being moved to Lumino)
• RateLimiter / IRateLimiter (being moved to Lumino)
• RestorablePool (IObjectPool, IRestorable, IRestorer)
• SettingRegistry / ISettingRegistry / Settings
• StateDB / IStateDB
• Text
• Throttler (being moved to Lumino)
• Time
• URLExt

For me the clearest candidates for being split off are the things that export Tokens, namely StateDB and the SettingsRegistry. These are larger components, that would benefit from being semvered independently.

Other candidates:

• RestorablePool: Similarly to the two above, this is also a larger component. The only difference is that it does not export a Token.
• Time: moment.js is a big dependency for what is marketed as a "util". See discussions in e.g. switch from moment.js to date-fns #7137
• nbformat: This could potentially be reused outside of JupyterLab, which would be easier if it was self-contained.
• PageConfig: Again a larger component that would benefit from independent semver, especially since it also needs to be in sync with the corresponding server component and the protocol they speak.
• Others?

I would very much like some input on which parts people think makes sense to split off, and which parts to keep in coreutils. We would also need to decide how to redistribute any such parts (move to other packages, make a new package per component, make a new package for some of the components). Note that this is also somewhat time critical to get in before we try to freeze the API for 2.0.

[vidartf]

One issue would also be to consider what this means:

jupyterlab/packages/coreutils/package.json

Line 58 in 3ba40d8

"coreDependency": true

And figure out which if any new packages should be marked similarly.

[blink1073]

Based on the in-person discussions today, I think we should make the following new packages:

• StateDB
• SettingsRegistry
• nbformat

The first two to aid in discoverability since they are token providers, and the last because its API is most likely to evolve over time. I think this strikes a good balance between package number and scope explosion.

[afshin]

If StateDB moves, does that mean IDataConnector and DataConnector and the restorable pool stuff should go with it?

SettingRegistry is simpler and totally makes sense to me. Same with nbformat.

[jasongrout]

If we're going to make a new package for nbformat, can we make the name such that moving other validation and message functions from services works too?

For example, serverapi, jupyterapi, jupyterserver, jupyterprotocol, @jupyterlab/protocol, etc.

[vidartf]

If we're going to make a new package for nbformat, can we make the name such that moving other validation and message functions from services works too?

To clarify for readers not in our previous call: @jasongrout is thinking to move some of the code that is part of the service refactor (validation and typings of server API messages) to a separate package for reuse by others. The suggestion seems to be that these live in the same package as nbformat. I think the rationale is that there would be overlap between the contributors to those two parts. Personally, I'm unsure if there would be significant overlap between the users of those two parts.