Visualiser: bundle the in-tree service-client#687
Merged
Conversation
The visualiser was the only JS service still consuming @amrc-factoryplus/service-client from the npm registry (^1.3.6), so the v6.1.0 images shipped a bundle without bearer_jwt support and JWT-authenticated sessions fell into the GSS /token path at runtime. CI has passed the lib build context all along; only this Dockerfile ignored it. Switch to file:../lib/js-service-client like every other service, copy the lib context in the Docker build with --install-links, and regenerate the lockfile (npm treats the lock as authoritative under --save=false, so the stale registry pin also had to go). The newer client needs webpack taught about node:-scheme imports and the GSS fork; all such modules are behind guarded dynamic imports so they stub to empty in the browser.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The v6.1.0-ago releases shipped a visualiser bundle built from the npm-published service-client 1.3.6: the visualiser was the only JS service still depending on the registry package instead of
file:../lib/js-service-client, and its Dockerfile ignored thelibbuild context CI has been passing all along. Result at runtime:bearer_jwtwas unknown to the bundled client, so after a successful Keycloak login the fetch layer fell into the GSS/tokenpath and died withGSS.createClientContext is not a function.package.json→file:../lib/js-service-client, lockfile regenerated (npm keeps the lock authoritative under--save=false, so the stale registry pin was load-bearing).libbuild context and installs with--install-links, matching the other services.node:scheme, stubfs/path/stream/async_hooksand the GSS fork. All are behind guarded dynamic imports with browser fallbacks, so stubbing is safe.Verified by building the image exactly as CI does (
docker build --build-context lib=./lib) and checking the produced bundle contains thebearer_jwt/jwt_mqttcode and service-client 1.6.0.How to test
Authorization: Bearer <JWT>(no/tokenrequest in the network tab) and the MQTT websocket should connect.🤖 Generated with Claude Code