Summary

On platforms without a prebuilt image (e.g. Apple Silicon / linux/arm64), make run falls back to a local Docker build (added in #13). On a fresh build that path was broken in two independent ways. This PR contains both fixes so make run works end-to-end: the image builds, and import torch in the first notebook cell is clean.

Fix 1 — labextension build crash (build:prod)

Problem

The local build aborts in the labext-builder stage at jlpm run build:prod:

TypeError: Cannot read properties of undefined (reading 'trim')
 at WebpackInnerModuleIterator.getActualFilename
 (license-webpack-plugin/dist/WebpackInnerModuleIterator.js:61)

The dev build is unaffected — the crash only happens in production mode.

Root cause

• @jupyterlab/builder adds JSONLicenseWebpackPlugin only in mode === 'production', which is why build:prod breaks but build:dev does not.

• That plugin uses license-webpack-plugin@4.0.2 (latest, unchanged since 2022). Its getActualFilename() assumes Module Federation "provide module" entries look like provide module ... = <path> and does filename.split('=')[1].trim().

• Modern webpack (5.107, what jlpm install resolves today) emits the extension's self-provided share with a pipe separator and no =:

  provide module (default) torchcode-labext@0.1.0|/app/lib/index.js
  

  so split('=')[1] is undefined and .trim() throws.

• The extension pins webpack@^5.76 (transitively) with no committed lockfile (labextension/yarn.lock is git-ignored), so a fresh jlpm install resolves a newer webpack that triggers this. The published :latest image predates that webpack bump, which is why it still works while a fresh build doesn't.

Fix

A minimal, declarative patch via Yarn resolutions + the patch: protocol (no lockfile needed; applied wherever jlpm install runs):

// before
return filename.split('=')[1].trim();
// after
var providedFile = filename.split('=')[1];
return providedFile == null ? null : providedFile.trim();

Returning null for a self-provided share is correct — it is the extension's own code, already excluded from the license report (excludedPackageTest). Behaviour is unchanged when an = is present.

• labextension/.yarn/patches/license-webpack-plugin-npm-4.0.2-*.patch — the one-line guard
• labextension/package.json — resolutions entry applying the patch
• Dockerfile — COPY labextension/.yarn before jlpm install so the patch exists at resolve time

Fix 2 — missing NumPy at runtime

Problem

With the build fixed, the container starts but import torch in the first notebook cell prints:

UserWarning: Failed to initialize NumPy: No module named 'numpy'
 (Triggered internally at .../tensor_numpy.cpp:84)

and tensor↔numpy interop (tensor.numpy(), from_numpy, ...) is disabled.

Root cause

torch >=2 treats NumPy as an optional dependency, so pip install torch (from the CPU index) does not pull it in, and nothing else in the image installs it.

Fix

Install numpy in the runtime stage (Dockerfile). torch-judge's package metadata is intentionally left unchanged — it doesn't import numpy directly, and Colab already ships numpy, so this only needs fixing in the Docker image.

Verification

• Reproduced the build crash on a clean jlpm install with the same resolved versions (@jupyterlab/builder@4.5.8, webpack@5.107.2, license-webpack-plugin@4.0.2); instrumented the plugin to capture the offending identifier.
• Host + Docker --target labext-builder (linux/arm64, Node 20): build:prod fails without the patch, succeeds with it; third-party-licenses.json is generated and the wheel is produced.
• Full image rebuild (docker compose build): succeeds, and import torch with -W error::UserWarning is now clean — torch 2.12.0+cpu, numpy 2.4.6, interop OK.
• This PR's docker-publish CI rebuilds the image from scratch (the package.json change busts the jlpm install layer cache), independently validating both fixes on linux/amd64.

No automated tests are added: the repository has no test suite, and these are build/runtime-tooling fixes whose validation is the Docker build itself (run by CI on every PR).