fix: add trailing slash to hardcoded kubeflow BASE_PATH in webpack config

[christian-heusel]

Summary

In production/Kubeflow-mode builds of workspaces/frontend, opening a route that requires a lazily-loaded webpack chunk (e.g. the Workspace details view) fails with a ChunkLoadError. The browser requests a malformed URL like /workspaces449.bundle.js instead of /workspaces/449.bundle.js, which doesn't match this frontend's Istio VirtualService prefix match (prefix: /workspaces/) and therefore never reaches the app's own nginx.

Root cause: config/webpack.common.js and config/webpack.dev.js hardcode BASE_PATH to the literal '/workspaces' (no trailing slash) whenever DEPLOYMENT_MODE === 'kubeflow':

const BASE_PATH = DEPLOYMENT_MODE === 'kubeflow' ? '/workspaces' : PUBLIC_PATH;

This value becomes webpack's runtime publicPath (__webpack_require__.p), which webpack's dynamic import() runtime uses via raw string concatenation with the chunk filename — it does not insert a / separator, since publicPath is expected to already end in one. So a chunk file 449.bundle.js gets requested as '/workspaces' + '449.bundle.js' = /workspaces449.bundle.js.

The entry bundle (app.bundle.js) is unaffected because html-webpack-plugin normalizes publicPath itself when injecting the <script> tag and <base href> into index.html — only dynamically imported chunks go through the raw webpack runtime and hit the bug. This is also why it's easy to miss in local dev: .env.tilt sets DEPLOYMENT_MODE=standalone and PUBLIC_PATH=/workspaces/ (with a trailing slash already), which takes the other branch of the ternary and never triggers the bug.

Fix

Add the missing trailing slash to the hardcoded kubeflow-mode literal in both files, matching what PUBLIC_PATH=/workspaces/ already does correctly for the non-kubeflow branch:

- const BASE_PATH = DEPLOYMENT_MODE === 'kubeflow' ? '/workspaces' : PUBLIC_PATH;
+ const BASE_PATH = DEPLOYMENT_MODE === 'kubeflow' ? '/workspaces/' : PUBLIC_PATH;

Verification

• Ran npm run build:prod and confirmed the built app.bundle.js now embeds __webpack_require__.p="/workspaces/" (previously "/workspaces"), so lazily-loaded chunks now resolve to /workspaces/<id>.bundle.js.
• Confirmed dist/index.html's <base href> and <script src> are unaffected (still correctly /workspaces/...) — only the runtime chunk-loading path was wrong before this change.
• npm run test:lint passes.
• Reproduced the original bug against a live Kubeflow Community distribution deployment (KIND cluster) before the fix: opening a Workspace's details panel threw ChunkLoadError: Loading chunk 449 failed. (missing: http://<host>/workspaces449.bundle.js) in the browser console, with the network request returning a non-2xx response since it doesn't match this service's Istio route.

Test plan

• npm run build:prod succeeds and the emitted app.bundle.js has publicPath = /workspaces/
• npm run test:lint passes
• Deploy to a cluster running the Kubeflow Community distribution manifests, open Notebooks v2 → Workspaces → click into a workspace's details panel, confirm no ChunkLoadError and the details panel renders (reviewer/CI verification)

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign paulovmr for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• workspaces/frontend/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[thisis-Shitanshu]

Tested this against a local KIND Kubeflow Community Distribution deployment.

I was able to reproduce the issue before the change: opening the Workspace details view requested lazy chunks such as /workspaces6990.bundle.js, which returned HTML in my environment and resulted in Unexpected token '<' followed by a ChunkLoadError.

I then built and deployed this PR and repeated the same flow with cache disabled. The chunk is now requested correctly as /workspaces/6990.bundle.js, returns application/javascript with 200, and the ChunkLoadError is gone.

The trailing slash change looks correct to me. LGTM 👍

[google-oss-prow]

@thisis-Shitanshu: changing LGTM is restricted to collaborators

Details

In response to this:

Tested this against a local KIND Kubeflow Community Distribution deployment.

I was able to reproduce the issue before the change: opening the Workspace details view requested lazy chunks such as /workspaces6990.bundle.js, which returned HTML in my environment and resulted in Unexpected token '<' followed by a ChunkLoadError.

I then built and deployed this PR and repeated the same flow with cache disabled. The chunk is now requested correctly as /workspaces/6990.bundle.js, returns application/javascript with 200, and the ChunkLoadError is gone.

The trailing slash change looks correct to me. LGTM 👍

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.