Remove `jupyterlab` dependency from `jupyter-builder`

[Darshan808]

Problem

Currently, jupyter-builder depends on jupyterlab to get core metadata:

jupyter-builder/jupyter_builder/core_path.py

Lines 4 to 10 in 880a31d

	from pathlib import Path
	def default_core_path() -> str:
	import jupyterlab
	return str(Path(jupyterlab.__file__).parent / "staging")

I discovered this in run-time CI failure on running jlpm run build
https://github.com/Darshan808/extension-template/actions/runs/21736558199/job/62702708930?pr=1

This has been discussed on following places
#12 (comment)
#29 (comment)

Proposed Solution from suggestions above

• Create a new lightweight npm package @jupyterlab/core-meta containing only metadata (package.json, version info, and things we need)
• Publish @jupyterlab/core-meta for all JupyterLab releases (retroactively and for future releases)
• Update jupyter-builder to read metadata from node_modules/@jupyterlab/core-meta/ instead of importing jupyterlab

Benefits

• Extensions can build without installing full JupyterLab package
• Eliminates circular dependency

[Darshan808]

CC: @krassowski @bollwyvl @jtpio
Feedback would be very helpful.

[krassowski]

So that's only used here:

jupyter-builder/src/extensionConfig.ts

Lines 75 to 77 in 880a31d

	const coreData = JSON.parse(
	fs.readFileSync(path.join(corePath, 'package.json'), { encoding: 'utf8' })
	);

And this is the file we need for each version:

https://github.com/jupyterlab/jupyterlab/blob/v4.5.3/jupyterlab/staging/package.json

We use three stanza:

• dependencies
• resolutions
• jupyterlab.singletonPackages

jupyter-builder/src/extensionConfig.ts

Lines 81 to 85 in 880a31d

	// Start with core package versions.
	const coreDeps: any = {
	...coreData.dependencies,
	...(coreData.resolutions ?? {})
	};

(should not have any there but that's another topic)

jupyter-builder/src/extensionConfig.ts

Lines 105 to 112 in 880a31d

	// Set core packages as singletons that are not bundled.
	coreData.jupyterlab.singletonPackages.forEach((element: string) => {
	if (!shared[element]) {
	shared[element] = {};
	}
	shared[element].import = false;
	shared[element].singleton = true;
	});

Some of it is already up on npm in @jupyterlab/metapackage:

https://www.npmjs.com/package/@jupyterlab/metapackage?activeTab=code

but dependencies are specified with ^ rather than ~ and there is no resolutions or jupyterlab.singletonPackages.

I guess we cannot use @jupyterlab/metapackage because:

• we would need more data
• we cannot override already published versions to add more data
• we want to publish the data, but we don't want to pull the dependencies. Ideally, we would just ship the package.json from staging renamed to metadata.json and keep the package.json of the new package to minimum

[krassowski]

Well, there is also option of just pulling from GitHub tags:

https://raw.githubusercontent.com/jupyterlab/jupyterlab/refs/tags/v4.5.3/jupyterlab/staging/package.json

In the world of Go it would not be considered crazy, but only if we enabled immutable releases to enforce immutable tags on GitHub (I am not sure if we can do that retrospectively).

There is also a higher guarantee of NPM availability over GitHub raw file download availability.

[krassowski]

For completeness, one more option would be to download the source tarball from PyPI which has good guarantees e.g. jupyterlab-4.5.3.tar.gz from https://pypi.org/project/jupyterlab/4.5.3/#files and then extract it to get the single file we need, but it would be a tad wasteful as the tarball weighs 23 MB.

[krassowski]

So yeah, I guess I concur with @bollwyvl suggestion from #12 (comment). I also agree that @jupyterlab/core-meta is a good name.

[krassowski]

Maybe we could use the GitHub download as a fallback strategy or for the past releases.