Open mummybot opened 3 years ago
I've fixed this for our project by doing two things:
style-inject
in the library's dependenciesIt works, but this seems like a hack for what should just work out of the box. Is there a reason for the relative import path to style-inject
? If so, can we make it configurable?
I'll raise a PR shortly
We are experiencing this issue as well, and have probably a very similar solution to @mummybot. For anybody else that encounters this problem while it remains unsolved in this plugin, here was the custom inline-plugin we built:
// rollup.config.js
export default {
// other rollup configurations...
plugins: [
// other rollup plugins...
postcss(),
{
name: 'Custom Rollup Plugin`',
generateBundle: (options, bundle) => {
Object.entries(bundle).forEach(entry => {
// early return if the file we're currently looking at doesn't need to be acted upon by this plugin
if (!entry[0].match(/.*(.scss.js)$/)) {
return;
}
// this line only runs for .scss.js files, which were generated by the postcss plugin.
// depending on the use-case, the relative path to style-inject might need to change
bundle[entry[0]].code = entry[1].code.replace(
'../../node_modules/style-inject/dist/style-inject.es.js',
'style-inject',
);
});
},
}
]
}
Looks like somebody already created a PR in May, but some tests are failing. https://github.com/egoist/rollup-plugin-postcss/pull/375/files
Let's see if this gets reviewed and merged :pray:
We are also running into this issue. Would love to see this get merged in!
Update: actually don't care if this gets merged in as we have found that style-inject has a flaw in that it will inject style tags in reverse order causing css priority issues. https://github.com/egoist/style-inject/issues/23. The lib has also not been touched in 4 years, so don't expect any fixes to go in. Rollup should move away from depending on this lib.
This is not a bug at all. It works properly because stylesInject is just a function from 'styles-inject' package, so we can allow it to be bundled. But it is not bundled because most likely you have this setting in your rollup.config.js:
external: [
/node_modules/
]
So, replace it with a code bellow and it will work:
external: (id) => {
if (/style-inject/.test(id)) return false;
if (/node_modules/.test(id)) return true;
return false;
},
also, you can write a regexp for it instead
The above answer is incorrect since it's assuming you do want to bundle everything together.
When you are generating a library with preserved modules, the nasty node_modules
folder for the relative import to work is not packed up by NPM. The configuration is definitely required, regardless of rollup keep using styleInject or not. When generating this kinda library you don't want relative imports and usually will prefer using peer dependencies instead (of some other way to bundle the dependency once for the final bundle).
If you do want to abide for the way rollup decided to implement this, you can "force" NPM to pack the nested modules by adding the folder explicitly on your package.json
:
"files": [
"dist/*",
"dist/node_modules/*"
],
Has this been resolved? I got this issue too
As a dependency , style-inject
should not be bundles with library. This pr also would reduce final bundle css, when using multiple libraries transformed with rollup-plugin-postcss
@egoist Could you accept this pr?
Is there any update on this? I'm running the same issue
Any update here? I have the same issue. Thanks,
We are experiencing this issue as well, and have probably a very similar solution to @mummybot. For anybody else that encounters this problem while it remains unsolved in this plugin, here was the custom inline-plugin we built:
// rollup.config.js export default { // other rollup configurations... plugins: [ // other rollup plugins... postcss(), { name: 'Custom Rollup Plugin`', generateBundle: (options, bundle) => { Object.entries(bundle).forEach(entry => { // early return if the file we're currently looking at doesn't need to be acted upon by this plugin if (!entry[0].match(/.*(.scss.js)$/)) { return; } // this line only runs for .scss.js files, which were generated by the postcss plugin. // depending on the use-case, the relative path to style-inject might need to change bundle[entry[0]].code = entry[1].code.replace( '../../node_modules/style-inject/dist/style-inject.es.js', 'style-inject', ); }); }, } ] }
This helped me out, thanks to @dandrewgarvin ! Just trying to make it more generic by changing the search value to a regex
postcss(),
{
name: 'Replace style-inject Rollup Plugin`', // it has to be after `postcss()`
generateBundle: (options, bundle) => {
Object.entries(bundle).forEach(entry => {
// early return if the file we're currently looking at doesn't need to be acted upon by this plugin
if (!entry[0].match(/.*(.scss.js)$/)) {
return;
}
// this line only runs for .scss.js files, which were generated by the postcss plugin.
bundle[entry[0]].code = entry[1].code.replace(
/[./]*\.\/node_modules\/style-inject\/dist\/style-inject.es.js/,
'style-inject',
);
});
},
},
Apologies if this is more of a usage question than a bug, I have posted here at Stackoverflow.
We are maintaining an internal library which is exporting ESM modules using Rollup. We have just recently switched to using CSS modules, which we have set with rollup-plugin-postcss. We want to inject these styles into the head rather than have an external file.
Our built bundle generates the ESM file with:
Our consuming library then fails with
I would expect the ESM export to
import styleInject from 'style-inject'
and style-inject to be included in the package-lock.json as a dependency. Even manually adding the dependency as part of our library which then includes it in the consuming app doesn't allow it to resolve. What is the correct way of using CSS Modules and injecting into the head for the consumer of a library?rollup.config.js