Update to JupyterLite 0.6.0a0

[jtpio]

Update to https://github.com/jupyterlite/jupyterlite/releases/tag/v0.6.0a0

Clean up some other jest related packages that don't seem to be used at the moment.

[github-actions]

👈 Try it on ReadTheDocs

[jtpio]

Also bumping these @jupyterlab packages, since jupyterlite-pyodide-kernel already closely follows jupyterlite-core releases, and jupyterlite-core follows minor JupyterLab releases.

[bollwyvl]

Sounds good, but same old question: how can we make this more predictable, and based on the truth from upstream's yarn.lock and package.json, and then doubly upstream's staging?

[jtpio]

What kind of predictability are we expecting?

In this case these @jupyterlab packages are used more like in regular extensions, and it's mostly minimal use of @jupyterlab/coreutils and @jupyterlab/services.

[bollwyvl]

If we're sticking with jlpm as the main task entry point:

jlpm
jlpm deduplicate
jlpm lint:upstreams

... and it checks vs a single source of truth that the not-going-to-space-if-wrong versions from the currently-installed python and js upstreams. It doesn't even have to fix them, just tell us what is wrong.

[bollwyvl]

Or, perhaps it would be more appropriate as a pytest which only runs if it's in a git checkout.

[jtpio]

ok, so probably something we could look into separately.

[jtpio]

@bollwyvl if that's ok, maybe we can go with this and I'll follow up with a pre-release right after? Unless you had more comments or inputs?

[bollwyvl]

can't really hurt anybody!

[jtpio]

Maybe we can first merge #161 to have it in 0.5.2?

[bollwyvl]

Created and re-targeted #161 against 0.5.x

[bollwyvl]

(feel free to re-re- target, and release in whatever order makes sense, likely won't be doing any conda-forge chores much longer today, but again, probably won't hurt anybody)

[jtpio]

ok no problem, I think we can still have #161 target main and then we backport to 0.5.x (usually how we do with other repos). I'll have a look!