Repository navigation
fix: explain invalid CSS module exports - #19
Conversation
|
fix: explain invalid CSS module exports — Independent OAuth2 review cleared pinned head a5c5695 against d42c36c. Exactly three frozen files and matching committed blobs; no actionable findings. The guard only applies to named-JavaScript generation, with actual bundle controls for Unicode/contextual/joiner names, custom conventions, CSS entry-point JSON and modules disabled. Diagnostics identify invalid keys and stylesheet paths without requiring error ordering. Caller documentation and the remapping example are valid. Final package check, eight suites / 56 steps and public doc lint passed; original source rejected 20 diagnostic steps while six compatibility controls passed. Declared and parsed closing sets are [18]. |
|
🎉 This PR is included in version 0.4.4 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Why
Importing a CSS module with keys such as
foo-bar,defaultorcsscurrently generates invalid JavaScript or duplicate stylesheet exports. Report these unsupported named exports as plugin build errors that identify the key and stylesheet and explain how to remap it.Validate transformed keys only when emitting JavaScript named exports. Preserve valid Unicode and contextual identifiers, custom naming conventions, CSS entry-point class maps and
modules: false. Document the existing named-export contract and supported remapping options.Verification
deno task check: passed.deno task test --parallel --reporter=dot: eight suites / 56 steps, zero failures.deno doc --lint postcss.ts: passed.Risk
Door: two-way. Previously valid exports keep their names and values. Unsupported keys already produced invalid generated JavaScript; they now produce actionable plugin errors. CSS entry points and JSON class maps retain arbitrary keys.
Tradeoffs
Preserve the existing named-export API. A default class-map export or arbitrary-name export API remains separate design work.
Closes
Closes #18