Skip to content

Conversation

@CyberAP
Copy link
Contributor

@CyberAP CyberAP commented Apr 22, 2025

Description

Add names field to asset entrypoints in manifest.

This allows you to map back your asset-only entrypoints to corresponding files in the bundle. This was not possible previously because asset entrypoints only had file, src and isEntry files, none of which included information about entrypoint name.

Copy link
Member

@sapphi-red sapphi-red left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change makes sense to me, and the implementation looks good.

Note: For non-CSS assets, the output file name cannot be adjusted based on the name specified in the input option. So in that case, this new property wouldn't be useful, but I think that's fine.

Instead of adding a test in packages/vite/src/node/__tests__/build.spec.ts, could you update the test in

expect(dirFooAssetEntry.file).toMatch('assets/bar-')
?
There's a similar entry for input already so you should be able to add an expect without adding a new entry.
entrypoints.push(['bar.css', path.resolve(__dirname, './dir/foo.css')])

@sapphi-red sapphi-red added p2-nice-to-have Not breaking anything but nice to have (priority) feat: build labels Apr 25, 2025
@CyberAP CyberAP force-pushed the provide-asset-names-in-manifest branch from b48363c to a066578 Compare April 25, 2025 14:12
@CyberAP
Copy link
Contributor Author

CyberAP commented Apr 25, 2025

@sapphi-red done!

Copy link
Member

@sapphi-red sapphi-red left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@patak-dev patak-dev modified the milestones: 6.4, 7.0 Apr 28, 2025
@sapphi-red sapphi-red merged commit c4e01dc into vitejs:main May 16, 2025
15 checks passed
moonlitusun pushed a commit to moonlitusun/vite that referenced this pull request May 25, 2025
Co-authored-by: Stanislav Lashmanov <slashmanov@gitlab.com>
@CyberAP
Copy link
Contributor Author

CyberAP commented Aug 8, 2025

I am trying this out and it seems that Vite transforms entrypoint names for some reason. If you get foo/bar.scss as your entrypoint name then it will get transformed to names: ['foo/bar.css'], notice the .css extension instead of .scss. This breaks lots of things for me.

I can not use .css extension for entrypoint names because if I use it for some reason Vite decides to switch the resolving mode: instead of resoling with absolute paths it resolves with relative paths. So for example url('module/my-font.woff') will now resolve to @fs/node_modules/module/my-font.woff instead of @fs/Users/me/project/node_modules/my-font.woff. Using anything but the .css in the entrypoint name fixes this problem.

I am not really sure how to proceed because one fix negates the other fix. @sapphi-red maybe you have thoughts on this?

@CyberAP
Copy link
Contributor Author

CyberAP commented Aug 8, 2025

Here's an illustrated example.

Entrypoint config:

{
  build: {
    rollupOptions: {
      input: {
        'styles/tailwind.scss': `${path.join(ROOT_PATH, 'app/assets/builds/tailwind.css')}`
      }
    }
  }
}

Manifest output:

{
  "builds/tailwind.css": {
    "file": "assets/tailwind-CefKy2DB.css",
    "src": "builds/tailwind.css",
    "isEntry": true,
    "names": [
      "styles/tailwind.css"
    ]
  },
}

I expected that entrypoint names would be preserved.

- "names": ["styles/tailwind.css"]
+ "names": ["styles/tailwind.scss"]

@sapphi-red
Copy link
Member

@CyberAP

I am trying this out and it seems that Vite transforms entrypoint names for some reason. If you get foo/bar.scss as your entrypoint name then it will get transformed to names: ['foo/bar.css'], notice the .css extension instead of .scss. This breaks lots of things for me.

This is to emit the file with .css extension. If Vite doesn't change the extension, rollup will output the extension as-is (so foo/bar.scss will be output instead of foo/bar.css).
It is done in this line:

const cssFullAssetName = ensureFileExt(chunk.name, '.css')

I guess we can fix this by saving the non-replaced one here and then using that here.

I can not use .css extension for entrypoint names because if I use it for some reason Vite decides to switch the resolving mode: instead of resoling with absolute paths it resolves with relative paths. So for example url('module/my-font.woff') will now resolve to @fs/node_modules/module/my-font.woff instead of @fs/Users/me/project/node_modules/my-font.woff. Using anything but the .css in the entrypoint name fixes this problem.

This sounds like a bug to me. Would you create an issue with a reproduction?

@CyberAP
Copy link
Contributor Author

CyberAP commented Aug 9, 2025

This is to emit the file with .css extension. If Vite doesn't change the extension, rollup will output the extension as-is (so foo/bar.scss will be output instead of foo/bar.css).

That's my problem with it. Entrypoint names are not files, they're just identifiers. So I have an entrypoint with a name foo.bar I don't expect it to suddenly change to foo.css in the manifest because I won't be able to find it anymore.

I guess we can fix this by saving the non-replaced one here and then using that here.

Thanks @sapphi-red! Do you want me to replace what we have in names already (breaking change) or just push the fixed name to this array? I think the assets are also missing name right now, maybe we should add this as well?

Would you create an issue with a reproduction?

Of course, I'll try to isolate the problem.

@sapphi-red
Copy link
Member

Do you want me to replace what we have in names already (breaking change) or just push the fixed name to this array?

I think we can replace it. I think the expected behavior is to have the same value that is set in the input option, rather than the internal value (the current one).

I think the assets are also missing name right now, maybe we should add this as well?

That makes sense to me. I guess we need to store whether the asset is specified as an entrypoint to achieve that.

@CyberAP
Copy link
Contributor Author

CyberAP commented Aug 10, 2025

Of course, I'll try to isolate the problem.

The problem was the following:

 {
   find: /^gitlab-(sans|mono)\//,
-  replacement: 'node_modules/@gitlab/fonts/gitlab-$1/',
+  replacement: '@gitlab/fonts/gitlab-$1/',
 },

I think this was not the issue with Vite but with our configuration. Changing this to a proper replacement fixed the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feat: build p2-nice-to-have Not breaking anything but nice to have (priority)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants