fix(css): use non-nested chunk name if facadeModule is not CSS file

[sapphi-red]

Description

#14945 changed the CSS chunk names to respect chunk name correctly.
That fixed the following cases:

• A CSS file is specified in build.rollupOptions.input (e.g. build.rollupOptions.input: { 'css/foo.css': 'css/foo.css' }) (Allow to specify filename of emitted CSS when build.cssCodeSplit: false #4863 (comment))
• build.rollupOptions.output.preserveModules: true is set (Some problems with cssCodeSplit and Library Mode #8057, The css file is not generated into the corresponding directory #12072)

But this also changed the CSS chunk name when a nested JS entry chunk imports a CSS chunk. For example,

build: {
  rollupOptions: {
    input: {
      'nested/foo.js': 'nested/foo.js' // nested/foo.js imports a CSS file
    }
  }
}

In this case, some people would want the CSS file to be output under nested directory, while others would want the CSS file to be output without nested directory.
The current behavior is the latter one, and this PR changes to the former one. But I'm not sure which is better. 🤔

refs #14945
refs #15141

Additional context

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines, especially the Pull Request Guidelines.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Update the corresponding documentation if needed.
• Ideally, include relevant tests that fail without this PR but pass with it.

[bluwy]

The current behavior is the latter one, and this PR changes to the former one. But I'm not sure which is better. 🤔

Do you mean the current behaviour is the former, and this PR changes to the latter instead? If I'm reading the PR right.

I tested the linked issues and it seems to not regress them, in which case if the only change is

But this also changed the CSS chunk name when a nested JS entry chunk imports a CSS chunk.

Then I think we can fix this so it returns to the behaviour as before. I think we could fix this as a patch since this output shouldn't be explicitly relied upon before.

[patak-dev]

I also think it is a good idea to get back to the previous behavior. I think it is less surprising that imported CSS works in the same way, no matter if they are imported from an entry or not (comment). So we keep the special handling only for entries.

It would be good if SvelteKit wouldn't depend on this though in the future.

[sapphi-red]

Do you mean the current behaviour is the former, and this PR changes to the latter instead? If I'm reading the PR right.

Oops. Yes 😅
👍 I'll add tests to this PR tomorrow.

[benmccann]

It would be good if SvelteKit wouldn't depend on this though in the future.

I don't think we do, but it was the issue fixed in #15154 which was causing us trouble. Now that it's fixed hopefully we don't depend on this anymore.

[patak-dev]

/ecosystem-ci run

[vite-ecosystem-ci]

📝 Ran ecosystem CI on 9bf031d: Open

suite	result	latest scheduled
analogjs	✅ success	✅ success
astro	✅ success	✅ success
histoire	❌ failure	❌ failure
ladle	✅ success	✅ success
laravel	❌ failure	❌ failure
marko	✅ success	✅ success
nuxt	❌ failure	❌ failure
nx	✅ success	✅ success
previewjs	✅ success	✅ success
qwik	✅ success	✅ success
rakkas	✅ success	✅ success
sveltekit	❌ failure	❌ failure
unocss	✅ success	✅ success
vike	✅ success	✅ success
vite-plugin-pwa	✅ success	✅ success
vite-plugin-react	✅ success	✅ success
vite-plugin-react-pages	✅ success	✅ success
vite-plugin-react-swc	✅ success	✅ success
vite-plugin-svelte	✅ success	✅ success
vite-plugin-vue	✅ success	✅ success
vite-setup-catalogue	✅ success	✅ success
vitepress	✅ success	✅ success
vitest	✅ success	✅ success