Fix postcss modules composes imports

[garthenweb]

↪️ Pull Request

The PR fixes different issues with postcss composes when using the import syntax, e.g. composes: my-class from './another-file.css';:

• importing the same file in different dependencies lead to duplicate CSS rules (Use of CSS Modules "composes:" results with duplicate classes exports #2592)
• importing other dependencies as CSS, e.g. sass files, the asset was not transpiled (CSS Modules not compatible using composes imports with SASS #2501)
• importing files using the parcel paths, e.g. composes: my-class from '~another-file.css throws an error because the file was not found (no ticket available)

Sorry for the big PR, I started fixing #2592 and found out that the issues are really closely related and it would not make sense to solve them separately (I drifted into a wrong direction when only thinking about one issue). Anyhow, all fixes are within separate commits (see the first 3).

Fixes: #2592, fixes #2501

💻 Examples

See the example in #2592 and #2501.

🚨 Test instructions

See the example in #2592 and #2501. I also tried to cover everything in integration tests.

✔️ PR Todo

• Added/updated unit tests for this change
• Test in bigger projects (with more edge cases, I just checked the example in Use of CSS Modules "composes:" results with duplicate classes exports #2592 for now)
• Test if it's working in combination with other Postcss transforms (CSS classes generated with a hash might be different in the dependency after parsed by parcel)
• Included links to related issues/PRs

[garthenweb]

@DeMoorJasper @devongovett I consider this one ready now, I am happy to receive feedback!

There is still one test failing, as far as I can see it is not related to my changes and also fails in master at the moment, therefore, I ignored it for now.

Some further notes I would like to share:
I tried to work around the custom Postcss Loader and the generateScopedName function in the first place, but had a hard time for multiple reasons.

• By default the Loader adds the imports on top of the asset. This introduced the duplicate CSS rules as it is not aware of other files.
• The imported CSS will not be transpiled in case its e.g. sass or less file. Even if we would run sass again afterward, the CSS classes are already defined and this by default based on a hash of its content. Therefore, when we add this dependency again by JavaScript, the hash will be different.
• Even if we disable to add the loaded CSS (see finalSource) it would create the class names based on the content, which is not working for transpiled files.
• As we already know about which classes are required for the other file in collectDependencies we could store them directly in the cssModules object and do not wait for Postcss at all, but this is only working when composes is used within one level (see test should support deep nested postcss composes imports).

The only chance I see to archive this without a custom loader would be to extend the Bundle to share information between assets as its implemented for Assets.replaceBundleNames already, but this would increase the overall complexity a lot. I started working on this in garthenweb@298d8cb but to many edge cases raised up.

I guess this is a good compromise between complexity and performance and when using css only it should still be possible to change the generateScopedName functions.

[DeMoorJasper]

You mentioned only one test failed but it seems a lot of tests are failing, could you resolve this?

[garthenweb]

Ahhhh, finally I understand the CI, never found the "test" tab and always tried to check the logs... Sorry for the circumstances!
My tests are a little naive implemented 🙈 Should be fixable, I will have a look.

[garthenweb]

Okay, the pipeline is now finally green.

Took a bit longer as one of the tests displayed an issue with the default file system loader on windows, which was most likely there before this PR: See 7e47b8d for the fix as well as css-modules/css-modules-loader-core#230 for the original issue.

[garthenweb]

I just made a small clean up for the Postcss loader and merge the master branch.

Maybe one more note: My team is using this for one week now without any issues and we also shipped it to production. It reduces the CSS bundle size by ~25% for us as we don't have duplicate classes within the bundle anymore, further it solved all issues we had with those duplicate CSS rules (caused by the changed specificity).

[DeMoorJasper]

Amazing works, thanks for this. Looks like it adds a lot of reliability to how parcel handles composes. Also great that you added so much tests to prevent issues with this in the future :)