Scope by the path relative to the build's working directory

[backspace]

Background and Goal

The first hash in a data-scopedcss-* attribute was the md5 of the component file's absolute path. Two builds of the same source at different paths, such as two CI runners or two developers' checkouts, therefore gave different attributes. In an app that prerenders HTML in one build and serves it with another build's CSS, the scoped rules then match nothing, and components render unstyled.

This identifies a file on disk by its path relative to the build's working directory (process.cwd()). Two checkouts that build from the same directory inside the checkout then give the same attribute. A filename that is not a file on disk (for example a synthetic module path a transpiler passes) is used as given, so those callers get the same prefix as before.

Key decisions and non-obvious mechanics

• The build's working directory is part of the identity. Builds that must agree have to run from the same directory inside the checkout. A build of the same source from another directory gives different prefixes.
• Both paths are resolved through symlinks. process.cwd() is always a real path. A filename reached through a symlink would otherwise give a relative path up to the root and back down, which holds the absolute path again.
• This changes every prefix a build emits for files on disk. That is a visible change for any consumer that stores rendered HTML, which must be re-rendered once. Labelled enhancement.
• Unit tests are new for this package. glimmer-scoped-css/tests/unique-identifier.test.cjs runs with node:test against the built dist, and the root pnpm test runs it before the test-app. With the old behaviour restored, the two working-directory tests fail.
• Verified in Boxel first. The same change is a pnpm patch in Scope glimmer-scoped-css styles by package-relative path boxel#6594. Its CI builds the host at two runner paths, and both builds give the same 259 CSS file names and the same 456 scope prefixes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RhwZUafCP38ur35n87R7BW

[backspace]

[Claude Code 🤖] The red Tests and Floating Dependencies checks both come from one test-app test, Acceptance | scoped css: an addon can use scoped styles (7 of 8 pass). That test also fails on main. The last CI run on main (2025-10-21) is red, its logs have expired, and a local run of main (with test-addon-to-import built) fails the same test with the same 7/8. The new node:test unit tests pass in both jobs (5/5).

[backspace]

[Claude Code 🤖] Root cause of the red an addon can use scoped styles test (also red on main): the scoped style is applied. Current Chrome reports the computed text-decoration shorthand without its default style keyword, as underline rgb(0, 0, 0), and the test compares against underline solid rgb(0, 0, 0). Checked on a bare page in Chrome 150 (CI runs 154): an element with text-decoration: underline solid rgb(0, 0, 0) reports the shorthand as underline rgb(0, 0, 0), while the longhands report underline / solid / rgb(0, 0, 0). In the built test-app the addon paragraph has the matching data-scopedcss attribute and computes underline rgb(0, 0, 0). A fix that does not depend on the browser's shorthand serialization is to assert textDecorationLine: 'underline' (and textDecorationColor) instead of the shorthand. Not part of this PR.