It seems that there is no interest to fix this 😢

We also unfortunately moved to Vite.

With multiple JS entrypoints (e.g. entry1.js, entry2.js), Parcel would usually output the bundles dist/entry1.js with dist/entry1.css and dist/entry2.js with dist/entry2.css. Note that the names don’t contain hashes because they have to be deterministic for you to be able to reference them wherever these end up being loaded.

Now Parcel tries to create shared bundles for CSS. Then one of the following can happen:

• If your two entrypoints have the exact same CSS imports, then the output is actually dist/entry1.js with dist/entry1.css and dist/entry2.js with no CSS bundle because it actually “reuses” dist/entry1.css, but that breaks the deterministic naming principle.
• If your two entrypoints have slightly different CSS, then the output is dist/entry1.js with dist/entry1.css (e.g. the common styles) and dist/entry2.js with dist/entry2.css but then also another CSS bundle for the styles unique to entry2. But that cannot also be named entry2.css, which is what the Bundle group cannot have more than one entry bundle of the same type error complains about.
• If your two entrypoints include the exact same CSS files but via some shared JS file (e.g. entry1+2 -> Layout -> styles.css), then it still fails with that error message for some reason. This is probably caused by some implementation detail of the bundler.

If I remember correctly, this should cover all of the cases I’ve seen so far.

EDIT: The reason that not everyone runs into this bug is that if you use HTML entries with Parcel, this works fine because there is no restriction to have deterministic names and so 2 CSS shared bundles are fine.

The code that determines which bundles are created and which files get put into which bundle is the bundler (docs).

As far as I can tell, Parcel doesn’t actually create shared JS bundles across entry points, so not creating shared CSS bundles might be a solution here.

@devongovett Any thoughts?

#9023 is still being reviewed but I’m hopeful it’ll fix this issue. I’m in the process of testing out the patch with one of our exhibiting codebases. I’ll report back when I have a result.

For what it’s worth, I’ve changed to Vite which seems to support this relatively easily.

Here’s my vite.config.ts:

import {defineConfig} from 'vite'
import react from '@vitejs/plugin-react-swc'
import * as path from "path";

// https://vitejs.dev/config/
export default defineConfig(({mode}) => ({
    plugins: [react()],
    build: {
        manifest: true,
        rollupOptions: {
            input: {
                foo: __dirname + '/src/foo/index.tsx',
                bar: __dirname + '/src/bar/index.tsx',
                // ...etc
            },
        },
    },
}))

We have a dozen or so entry points and it’s all straightforward.

Hi, I wonder if this is a complicated issue that only the maintainer can solve, or if someone can guide people by sharing info, for example, which codebase or related materials we can read to help this issue?

Sorry I forgot to report back. #9023 didn’t fix the issue for me. I intend to find a solution to this issue since other bundlers can’t scale for us the way Parcel can. Not sure when I’ll get the time to dig deeply on this one but it’ll happen.

One thing I should have noted in my comment: the reason that not everyone runs into this bug is that if you use HTML entries with Parcel, this works fine because there is no restriction to have deterministic names and so 2 CSS shared bundles are fine.

any news here? After 2,5 years parcel still doesn’t support two .scss files in the same project…

Hate to say it, but my solution was just to move to Vite

Apparently it doesn’t create a shared bundle.