IS-11682 Consume UI Kit CSS from source instead of the built artifact - #290
IS-11682 Consume UI Kit CSS from source instead of the built artifact#290urre wants to merge 8 commits into
Conversation
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ases. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR switches workspace consumers to import Curity UI Kit CSS from the @curity/ui-kit-css source entry (via an exports map) instead of relying on a prebuilt artifact, reducing the need for prebuild/watch steps while keeping a legacy path available.
Changes:
- Updated JS/CSS consumers to import
@curity/ui-kit-css(source) instead of@curity/ui-kit-css/.../dist/index.css. - Simplified build/start scripts across apps by removing CSS-lib prebuild/watch steps and related Vite watch plugin logic.
- Added an
exportsmap to@curity/ui-kit-cssto expose the source entry and keep a legacy./lib/dist/index.csssubpath.
Reviewed changes
Copilot reviewed 19 out of 20 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| src/self-service-portal/app/src/main.tsx | Switch CSS import to @curity/ui-kit-css source entry. |
| src/self-service-portal/app/previewer/main.tsx | Switch CSS import to @curity/ui-kit-css source entry. |
| src/self-service-portal/app/package.json | Remove CSS-lib watch/build presteps from scripts. |
| src/identity-server/vite.config.ts | Remove the CSS-lib watch plugin now that source is in the module graph. |
| src/identity-server/styles/index.js | Switch CSS import to @curity/ui-kit-css source entry. |
| src/identity-server/package.json | Remove CSS-lib build/watch steps from dev/build scripts. |
| src/haapi-react-app/src/shared/util/css/styles.css | Update @import to @curity/ui-kit-css. |
| src/haapi-react-app/previewer/shared/styles/previewer.css | Update @import to @curity/ui-kit-css. |
| src/haapi-react-app/package.json | Remove CSS-lib watch/build presteps from scripts. |
| src/common/css/package.json | Add exports map to expose source CSS and preserve legacy dist path. |
| src/common/css/lib/readme.md | Update documentation import to @curity/ui-kit-css. |
| src/common/css/lib/package.json | Remove legacy postwatch copy step from CSS-lib package scripts. |
| src/common/css/docs/src/pages/introduction/gettingstarted.mdx | Update docs snippet to import @curity/ui-kit-css. |
| src/common/css/docs/src/pages/index.mdx | Update docs snippet to import @curity/ui-kit-css. |
| src/common/css/docs/src/components/BaseHead.astro | Update docs head import to @curity/ui-kit-css. |
| src/common/component-library/package.json | Remove @curity/ui-kit-css from prebuild workspace builds. |
| package.json | Remove CSS packages from root prestart build chain. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
| "start": "vite", | ||
| "watch": "vite build --watch", | ||
| "prebuild": "npm run build --workspace @curity/ui-kit-icons --workspace @curity/ui-kit-css || true", | ||
| "prebuild": "npm run build --workspace @curity/ui-kit-icons || true", |
There was a problem hiding this comment.
@curity/ui-kit-css is now an unused dependency of this package (line 45). Dropping it from prebuild here removed the last reference to it — nothing under src/common/component-library/ imports the CSS, only the README mentions it.
Worth removing the dependency line in the same PR, since this PR is exactly about who depends on that package.
There was a problem hiding this comment.
Removed in 06ef4bf. One nuance worth recording: the component styles do consume @curity/ui-kit-css theme variables at runtime (--color-primary, --button-border-radius, --form-field-*, ...), so the host app still has to load the CSS — it's just not resolvable as an npm dependency. Moved the README mention to a "Runtime Requirements" section saying exactly that.
| "start:docs": "npm start -w docs", | ||
| "start:lib": "npm start -w lib", | ||
| "start": "npm-run-all -p start:docs start:lib", | ||
| "start": "npm run start:docs", |
There was a problem hiding this comment.
start:lib is orphaned now — nothing calls it once start stops doing so. Given lib/index.html says "Nothing to see here. See the src/common/css/docs project", dropping the lib dev server looks right, but then remove start:lib too, and start in lib/package.json with it. (concurrently in lib's dependencies is already unused today, if you want to sweep that as well.)
Separately, this is the one behaviour change the description doesn't mention: "npm start brings up all five dev servers" is still true, but start:css now serves only the docs, not the lib playground on :5176. One line in the description saves the next person working it out from the diff.
There was a problem hiding this comment.
All done in 7d57454:
- Removed
start:libhere andstartinlib/package.json, plus the unusedconcurrentlydependency and the now-deadserverblock inlib/vite.config.js(it only configured the dev server we just dropped). - Kept
lib/index.htmlandmain.js— they looked dev-server-only but are actually the Vite build entry that producesdist/index.css, so they stay. - PR description now mentions the behaviour change:
start:cssserves only the docs, the :5176 lib playground is gone.
| "main": "index.js", | ||
| "exports": { | ||
| ".": "./lib/src/main.css", | ||
| "./src/*": "./lib/src/*", |
There was a problem hiding this comment.
Is this entry needed? Nothing in the repo imports @curity/ui-kit-css/src/… — I grepped every source extension on this branch.
An exports map is a contract, and each entry is one more path that has to keep working, so if this is speculative I'd drop it and add it when something actually wants a single partial. If it's here to replace the @curity/ui-kit-css/* tsconfig aliases you removed, note those pointed at src/packages/css/*, which doesn't exist in either workspace.
There was a problem hiding this comment.
Dropped in 15b41ac. Confirmed it was speculative: nothing on the branch imports @curity/ui-kit-css/src/…, and the removed tsconfig aliases it might have replaced pointed at src/packages/css/*, which doesn't exist in either workspace — they were already dead. The only consumer of individual partials is identity-server's static-copy glob, which goes through the filesystem, not the exports map. Verified identity-server, SSP, HAAPI app, and docs all build clean without it.
| }, | ||
| }, | ||
| ], | ||
| plugins: shared.plugins, |
There was a problem hiding this comment.
Redundant now — ...shared on the line above already carries plugins. Keeping the explicit key reads as "styles mode differs here", which it no longer does. Just delete the line.
| name: "watch-css-lib-source", | ||
| buildStart() { | ||
| if (this.meta.watchMode) { | ||
| this.addWatchFile(path.resolve(__dirname, "../common/css/lib/src")); |
There was a problem hiding this comment.
Question, not a defect. The module graph does replace this for edits to existing partials — that reasoning is sound and your marker test proves it.
But addWatchFile was pointed at the lib/src directory, so it also covered files that don't exist yet, and the module graph can't: a newly added top-level CSS file that main.css doesn't @import but the !(main|curity-application).css static-copy target does pick up (a second theme, say) won't trigger a rebuild during npm run dev. Restarting the watcher fixes it, so I'm fine leaving this — I'd just rather it were a decision than something we rediscover in six months.
There was a problem hiding this comment.
Agreed, and making it the decision: new top-level CSS files added while watching require a watcher restart — accepted trade-off for dropping the plugin, since adding a new theme file is a rare event next to editing existing partials, which the module graph covers. Recorded it in f808b75 as a comment on the static-copy target in vite.plugins.ts, so it's found where the gap would be noticed instead of rediscovered.
| "exports": { | ||
| ".": "./lib/src/main.css", | ||
| "./src/*": "./lib/src/*", | ||
| "./lib/dist/index.css": "./lib/dist/index.css" |
There was a problem hiding this comment.
Who is the legacy consumer? @curity/ui-kit-css is private: true, so nothing outside this monorepo can install it, and after this PR nothing inside imports ./lib/dist/index.css either. Neither the Gradle product build (npm run build --workspace=@curity/ui-kit-identity-server) nor either GitHub workflow runs the lib build — only root npm run build and npm run build:css do, so the entry is backed, just unused.
If there's a concrete consumer, naming it in the description (or a comment in this package) stops the next person deleting it. If there isn't, @curity/ui-kit-css-lib could collapse into @curity/ui-kit-css — separate ticket, not this PR.
There was a problem hiding this comment.
Legacy consumer = external users of this public repo, not anything in the monorepo. Two cases:
- Old deep imports in customer forks/extensions. Until this PR the only import path was
@curity/ui-kit-css/lib/dist/index.css(SSP, HAAPI app, and the docs all used it). This PR introduces an exports map, and exports maps block any subpath they don't list — so without the"./lib/dist/index.css"entry, that previously-valid import breaks for anyone rebasing a fork or importing from a checkout. The entry is a compat shim for the old contract, not a new one. - No-bundler consumers. A plain HTML page or velocity template override can't inline
@imports — it needs the flatdist/index.cssfromnpm run build:cssto<link>. Those users copy the file rather than resolve the package, which is why the build script stays even though nothing internal runs it.
Agreed it should be written down — I'll add a comment in the package.json/description naming both.
The install notes in the docs have also been updated in c3837cf: gettingstarted.mdx now states the package is not on the npm registry and documents both consumer paths (bundler source import and the no-bundler build:css + <link> flow), and the unused Install.mdx snippet no longer suggests npm install @curity/ui-kit-css.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…itation. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Previously, workspace packages had to build
@curity/ui-kit-css-libbefore they could use it. This isn't needed. TheCurity CSS library is a Vite build that inlines
@imports and minifies, which every consumer (Vite, Rollup, Astro)already does to any CSS in its module graph.
Consumers now import the source entry through an exports map on
@curity/ui-kit-css, so there is nothing to buildfirst.
Who still needs the built artifact
The build script and the
"./lib/dist/index.css"exports entry stay for external users of this public repo (nothingin the monorepo uses them anymore):
@curity/ui-kit-css/lib/dist/index.css— introducing an exports map blocks any subpath it doesn't list, so thisentry keeps the previously-valid import working.
npm run build:cssto<link>directly.Benefits
watch-css-lib-sourceVite pluginnpm startstill brings up all five dev servers, butstart:cssnow serves only the CSS docs — the lib playgroundon :5176 is gone (its page was already a "nothing to see here" stub), along with the orphaned
start:lib/startscripts and the lib's unused
concurrentlydependencyVerification
tsc -blib/distdeleted entirely, every workspace still builds and identity-server'smain.csscame out identicalutilities-color.cssduringwatch:stylesand it landed in the outputnpm startbrings up all five dev servers with no errors; SSP dev resolves the import to/@fs/…/css/lib/src/main.cssand serves it with the partials inlined