Bump rspack to v2.0.0

[Darshan808]

Fixes #70

[Darshan808]

Build fails with error:

Error: node_modules/@rspack/core/compiled/http-proxy-middleware/index.d.ts(8,30): error TS2307: Cannot find module '@hono/node-server' or its corresponding type declarations.
Error: node_modules/@rspack/core/compiled/http-proxy-middleware/index.d.ts(9,35): error TS2307: Cannot find module 'hono' or its corresponding type declarations.

[krassowski]

I don't think we should have hono as a dev dependency. I asked over in chimurai/http-proxy-middleware#1219

[krassowski]

I downloaded a wheel from downstream test here and see references to 1.7.11:

$ grep -r "rspack" .
./jupyterlab/themes/@jupyterlab/theme-dark-extension/index.js:(()=>{"use strict";var r={},t={};function e(s){var o=t[s];if(void 0!==o)return o.exports;var u=t[s]={exports:{}};return r[s](u,u.exports,e),u.exports}e.rv=()=>"1.7.11",e.ruid="bundler=rspack@1.7.11"})();
./jupyterlab/themes/@jupyterlab/theme-light-extension/index.js:(()=>{"use strict";var r={},t={};function e(s){var o=t[s];if(void 0!==o)return o.exports;var u=t[s]={exports:{}};return r[s](u,u.exports,e),u.exports}e.rv=()=>"1.7.11",e.ruid="bundler=rspack@1.7.11"})();

Is this an issue with downstream tests not properly rewiring the downstream build to use the latest version?

[Darshan808]

Is this an issue with downstream tests not properly rewiring the downstream build to use the latest version?

I think its because the the downstream JupyterLab still pins @rspack/core to 1.7.8 in its own packages,
I see this structure:

downstream/ (jupyterlab)
    node_modules/
        @jupyter/builder/
                node_modules/ 
                    rspack core 2.0.0
        @rspack/
             core: 1.7.8

• @rspack/core@1.7.8 at the top level (satisfying JupyterLab's pinned deps)
• @rspack/core@2.0.0 nested inside @jupyter/builder/node_modules/ (satisfying builder's requirement)

One way to test jupyterlab on rspack 2.0 is to explicitly add @rspack/core to resolutions in the root package.json just like we do we @jupyter/builder:

Like this:

downstream/package.json
{
  "resolutions": {
    "@jupyter/builder": "file:/Users/darshan/dev/opensource/jupyter-builder/jupyter-builder-0.0.8.tgz",
    "@rspack/core": "2.0.0"
  }
}

What do you suggest ?

[krassowski]

Could we remove @rspack/core from JupyterLab direct dependencies and make it only a transitive dependency?

[Darshan808]

I think that approach makes sense.

However, there’s an issue. In several places, JupyterLab invokes the rspack CLI directly, for example:

"build": "npm run clean && rspack --config webpack.config.js",

This assumes that the rspack binary is available in node_modules/.bin. But if we make rspack only a transitive dependency, its binary is not linked there, causing the build to fail.

One possible approach could be to ensure that rspack is explicitly exposed during installation of @jupyter/builder ?

[krassowski]

Another approach would be to remove the rspack invocations from JupyterLab scripts and replace them with a builder alias pointing to rspack, but at the end it would end of the day we would end up with a leaky abstraction as any special config downstream would need to refrence rspack anyways.

One way to test jupyterlab on rspack 2.0 is to explicitly add @rspack/core to resolutions in the root package.json just like we do we @jupyter/builder:

I think this is the least invasive way forward for now.

[Darshan808]

Locally confirmed that modifying packages/services/rspack.config.js as done in jupyterlab/jupyterlab#18467 fixes the build issue and successfully builds jupyterlab.

-    library: '@jupyterlab/services',
-    libraryTarget: 'umd',
-    umdNamedDefine: true,
      
+   library: {
+      name: '@jupyterlab/services',
+      type: 'umd',
+      umdNamedDefine: true
+   },

Extensions also do not seem to be affected.

[Darshan808]

I added the patch to downstream test CI, and the JupyterLab build passes successfully. The Notebook build also passes. Only an upgrade to Rspack v2 is required on notebook side, with no additional changes.

However, when downloading and inspecting the JupyterLab wheel from CI, there are still references to v1.7.8, as noted earlier.

I believe this is because we only added Rspack v2 in the resolutions field, while several package.json files still explicitly reference v1.7.8. After updating all of those to v2 and rebuilding the wheel locally, there are no remaining references to v1.7.8.

I guess for final testing, we could update CI to modify rspack version on each package.json once we’re ready to merge this.

Also, jupyterlab/jupyterlab#18467 still seems relevant unless we decide to completely remove the dependency on Rspack from core, as discussed earlier. After this PR gets merged and released, we could continue work there.

[krassowski]

Also, jupyterlab/jupyterlab#18467 still seems relevant

Indeed. Do you want to try resolving conflicts there?

[krassowski]

https://github.com/web-infra-dev/rspack/releases/tag/v2.0.2 is up 🎉

[Darshan808]

So shall we remove this temporary patch in CI and merge it ?

[Darshan808]

Removed the patch. I believe we can merge this one with failing CI.

[krassowski]

Thank you!