Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming dynamic chunks #2793

Closed
jakearchibald opened this issue Apr 7, 2019 · 9 comments
Closed

Naming dynamic chunks #2793

jakearchibald opened this issue Apr 7, 2019 · 9 comments

Comments

@jakearchibald
Copy link
Contributor

Feature Use Case

When using import(…) for code-splitting, the file is named chunk. When you have a lot of imports, you end up with a lot of similarly-named files, and it's difficult to debug.

Feature Proposal

Webpack uses /* webpackChunkName: "whatever" */, which works, but I personally find it a bit hacky and fragile. https://webpack.js.org/guides/code-splitting/

Alternatively, chunkFileNames could be a function which is given the path of the chunk entry point, and returns the naming pattern. Then developers could look at the name/path and return a meaningful name.

@lukastaegert
Copy link
Member

I agree that I would like to avoid a comment syntax. Only problem is that not all chunks have a natural "entry point" (though at the moment, dynamically imported modules ARE usually entry points, but this may change in the future, especially if we enable more control how modules are grouped into chunks in the future). What we could provide is a slightly stripped down version of what bundle.generate returns per chunk (which can also contain a facadeModuleId), will think about it.

@jakearchibald
Copy link
Contributor Author

What we could provide is a slightly stripped down version of what bundle.generate returns per chunk (which can also contain a facadeModuleId)

That sounds reasonable.

@lukastaegert
Copy link
Member

As a first step to improve upon the initial issue, #2809 will add the name of the imported module as [name] for dynamic imports.

@jakearchibald
Copy link
Contributor Author

Nice! This has improved some of our chunks. A lot are still named 'chunk', but it's a step in the right direction.

@lukastaegert
Copy link
Member

To solve names for the remaining modules, another thing we could easily do is used the basename of the last module in the execution order of an auto-generated chunk as [name]. As dependencies are always sorted first, this should often be a reasonable approximation of what the chunk is about. What do you think? I guess I will also set up a PR to play around with soon.

@shellscape
Copy link
Contributor

Hey folks. This is a saved-form message, but rest assured we mean every word. The Rollup team is attempting to clean up the Issues backlog in the hopes that the active and still-needed, still-relevant issues bubble up to the surface. With that, we're closing issues that have been open for an eon or two, and have gone stale like pirate hard-tack without activity.

We really appreciate the folks have taken the time to open and comment on this issue. Please don't confuse this closure with us not caring or dismissing your issue, feature request, discussion, or report. The issue will still be here, just in a closed state. If the issue pertains to a bug, please re-test for the bug on the latest version of Rollup and if present, please tag @shellscape and request a re-open, and we'll be happy to oblige.

@frank-dspeed
Copy link
Contributor

Only for reference, this is now finally solved via #3658

@TheComputerM
Copy link

@frank-dspeed How is /* webpackChunkName: "whatever" */ implemented in rollup? Can you give me a small example on how to use it.

@wtho
Copy link

wtho commented Jan 12, 2022

@TheComputerM
This should do:

  output: {
    chunkFileNames: (chunkInfo) => {
      if (chunkInfo.name === 'original-chunk-name') {
        return 'assets/funky-chunk.js'
      }
      return 'assets/[name].[hash].js'
    }
  }

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

No branches or pull requests

6 participants