-
Notifications
You must be signed in to change notification settings - Fork 233
RFC | leverage css module imports in components #5221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Branch previewReview the following VRT differencesWhen a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:
If the changes are expected, update the |
Tachometer resultsCurrently, no packages are changed by this PR... |
Pull Request Test Coverage Report for Build 14094674923Details
💛 - Coveralls |
75cfee3
to
2a1ea92
Compare
a09f6ee
to
84afd94
Compare
60cb2a0
to
43313e8
Compare
43313e8
to
0fbbce6
Compare
b1cedb8
to
b679f84
Compare
b679f84
to
841ed84
Compare
Found a possible polyfill solution: https://github.com/guybedford/es-module-shims?tab=readme-ov-file#css-modules |
841ed84
to
abab690
Compare
Description
We opened this as a demo of using the native CSS module imports for the web components (reference: https://web.dev/articles/css-module-scripts) and wondering if there are any decent polyfills that could get us the coverage we need to switch over to it.
This approach would mean in future infrastructure we wouldn't need to convert
*.css
->*.ts
->*.js
at all. One less thing to ship (and have to maintain as a part of our API too). Since we export them as part of our components here, I didn't remove the tasks that generate the*.css.js
files but if we committed to an approach like this, we could remove those in a future breaking change.Action items