Assets entries in the manifest do not preserve the original file extension

Describe the bug

#6649 added assets to the manifest, but the entries are invalid for Sass/Less/Stylus stylesheets, as it’s erasing the original extension from the manifest entry names and src.

For example, for style.scss the entry is:

  "style.css": {
    "file": "assets/style.a5c756ae.css",
    "src": "style.css"
  }

In contrast, Vite does preserve .ts extensions:

  "main.ts": {
    "file": "assets/main.ts.a1959a64.js",
    "src": "main.ts",

For any backend integration to map files correctly, it’s desirable to preserve the extension for assets as well:

  "style.scss": {
    "file": "assets/style.a5c756ae.css",
    "src": "style.scss"
  }

Background 📜

This is the behavior that vite-plugin-ruby implements, but it no longer works with Vite 3.

I believe this change is currently preventing Vite Ruby from trying to recover the original extension, making #6649 a breaking change for many Vite Ruby projects.

If the manifest preserves the extensions, this would greatly simplify all backend integrations, including Vite Ruby.

Reproduction

Run npm run build or see the manifest, notice that both the entry name and the src are incorrect.

Additionally, this failing test run demonstrates the issue.

System Info

System:
    OS: macOS 12.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 109.84 MB / 16.00 GB
    Shell: 3.3.1 - /opt/homebrew/bin/fish
  Binaries:
    Node: 16.13.1 - /var/folders/j6/gyvfxjy50jqgy9lth08nd_f40000gn/T/fnm_multishells/3581_1656077025812/bin/node
    Yarn: 1.22.17 - /var/folders/j6/gyvfxjy50jqgy9lth08nd_f40000gn/T/fnm_multishells/3581_1656077025812/bin/yarn
    npm: 8.1.2 - /var/folders/j6/gyvfxjy50jqgy9lth08nd_f40000gn/T/fnm_multishells/3581_1656077025812/bin/npm
  Browsers:
    Chrome: 102.0.5005.115
    Firefox: 101.0
    Safari: 15.2

Used Package Manager

pnpm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn’t already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it’s a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[innocenzi]

Yes, I also had issues with my current manifest generation, I had to change my implementation.

Additionally, is it possible to add an isEntry boolean to CSS files that are used in build.rollupOptions.input? This is needed for avoiding FOUCs - I didn’t realize https://github.com/vitejs/vite/pull/6649 didn’t do that, without it we still need to override the manifest in my integration and the official Laravel one

[ElMassimo]

I have a fix for the extension, currently looking into the isEntry piece.