ESM importing non-js files/chunks

[stropho]

Feature Use Case

I'd like build our UI library in a way that CSS modules stay CSS modules, so that the library users can do both ES and CSS modules tree-shaking
Let's say I have a following structure in the lib:

src
├── componentA
│   └── index.js
│   └── css-module.css
├── componentB
│   └── index.js
│   └── css-module.css
├── [...many more components]
└── index.js

And I'd like builld it to ESM like this

dist
├── chunks
│   └── chunk-123.js
│   └── css-module-567.css
│   └── css-module-678.css
└── index.js

and the file dist/index.js would still contain import css from 'css-module-567.css' etc.

Why would I want that?

w1. having library to be used in web app that does its own bundling and treeshaking
w2. benefit from rollup's file name hashing to give the developer a hint that some files should not be used directly
w3. don't create a plugin with writeFileSync() as I saw in a few plugins, keep all the files in rollup, and possibly transform css modules (e.g. from SASS to CSS) by other plugins

Feature Proposal

I have questions rather than a proposal 😄

1. Is that already possible and I just haven't figured out the correct configuration?
2. Would such a feature be available with export default import.meta.ROLLUP_CHUNK_URL_${chunkId} ? Allowing plugins to inject dynamic dependencies of a module #2742
3. If not, is there another way how to solve with with a plugin not using some (hacky) workaround?

Or maybe you tell me I got all wrong 😃

[tivac]

@modular-css/rollup already handles w3 using the asset APIs in rollup.

w2 is possible using the assetFileNames config option if the plugin uses the asset APIs.

I don't know of a plugin that avoids transforming the import statements though, if you shipped for without removing those the consumer would have to set up their bundler to understand CSS also. Maybe that's what you're looking for though?

[stropho]

...consumer would have to set up their bundler to understand CSS also.

Yes that is actually what I'm looking for in order to easily remove the unused css modules from the final bundle. (I'm working on and internal library for internal projects with similar devstack - using css modules)

Well nobody else replied, I guess I'll wait for #2742 / #2809 PR and see if that helps. I can always re-open ...