Stale @jupyterlab/collaboration dependency on main branch

[krassowski]

Both @jupyter/collaboration and @jupyterlab/collaboration are defined as dependencies on the main branch:

jupyter-ai/packages/jupyter-ai/package.json

Lines 63 to 68 in d6d34a5

	"@jupyter/collaboration": "^1",
	"@jupyterlab/application": "^4",
	"@jupyterlab/cells": "^4",
	"@jupyterlab/codeeditor": "^4",
	"@jupyterlab/codemirror": "^4",
	"@jupyterlab/collaboration": "^3",

But only the former is actually used:

jupyter-ai/packages/jupyter-ai/src/index.ts

Line 9 in d6d34a5

import { IGlobalAwareness } from '@jupyter/collaboration';

This leads to problems with tokens because two versions (v1 and v2) of @lumino/coreutils get pulled as can be seen in the lockfile:

jupyter-ai/yarn.lock

Lines 3716 to 3730 in d6d34a5

	"@lumino/coreutils@npm:^1.11.0 || ^2.0.0, @lumino/coreutils@npm:^1.11.0 || ^2.1.1, @lumino/coreutils@npm:^2.1.0, @lumino/coreutils@npm:^2.1.1":
	version: 2.1.1
	resolution: "@lumino/coreutils@npm:2.1.1"
	checksum: dfdeb2b0282caae17b6c3edfebadf4ce7c75fc879fa60cacfef9b154412f4b35e4ffd95b1833b99d8dacb99aaaa04513570129ae2024c3f33e2677a01f0576ce
	languageName: node
	linkType: hard
	"@lumino/coreutils@npm:^1.11.0, @lumino/coreutils@npm:^1.12.1":
	version: 1.12.1
	resolution: "@lumino/coreutils@npm:1.12.1"
	peerDependencies:
	crypto: 1.0.1
	checksum: 55f1b87997f8dd0af28ff23c2d4b3aa252e515b9d3bc91b350a5c6c8526ceae61b14b55dc0d8d01691c69d42974b3d559f2b49bc7ced0f474b8f5dc52b3e83ed
	languageName: node
	linkType: hard

This was introduced during upgrade to JupyterLab 4 (#296) which I think should have removed @jupyterlab/collaboration from the list of dependencies as it was never released with a support for v4 (https://www.npmjs.com/package/@jupyterlab/collaboration?activeTab=versions). Also that PR did this change:

- import { IGlobalAwareness } from '@jupyterlab/collaboration';
+ import { IGlobalAwareness } from '@jupyter/collaboration';

so it appears that not removing @jupyterlab/collaboration was an omission.

This issue bitten me in #465; I will likely include a fix in there but let me know if you prefer a separate PR.

[dlqqq]

@krassowski This seems like a separate issue, and thus I'd like it to be fixed in a separate PR if possible. Migrating the change from #465 into a separate branch and then rebasing #465 atop it might be a bit tricky, but it should be possible with an interactive rebase.