Should tsdown emit output files with or without hashes by default?

[sxzz]

Hi everyone,

We're discussing (issue #177) whether tsdown should include hashes in output filenames by default (e.g., MyComponent-[hash].js) or not (e.g., MyComponent.js). Some users feel that hashes are unnecessary and non-standard for npm packages, while others note that tools like Vite, tsup, and unbuild use hashes by default.

Please note:

• This discussion is specifically about chunk filenames, not entry filenames.
• For both library authors and library consumers, the chunk filename does not affect how the library is used or imported—it's an internal implementation detail.

Important note:
If hashes are disabled and two files would have the same name, tsdown will automatically add a numeric suffix to avoid conflicts (for example, MyComponent.js, MyComponent1.js, etc.).

We'd like to hear from the community to help determine what the default behavior should be. Please vote for the option that best reflects your preference or experience.

If you have additional thoughts, please leave a comment explaining your reasoning or sharing your use case. Your feedback will help us make a decision that best serves the community!

Thank you!

[posva]

I would say without a hash because that way they get overridden even without a clean: true. Otherwise they could pile up locally and accidentally augment package size

[hyf0]

For the chunk filenames:

• in rollup, the name of the chunk is acually the first module name in that chunk.
• in esbuild, the name of the chunk is chunk.
• in webpack, webpack will try to pull all names of modules together and does a cut if final name is too long.

What I'm confusing is the name of the chunk seems non-meaningful. It gets changed easily when import relationships get changed.

I prefer hash, it perfectly represents the concept of chunk is nothing but a set of modules.

[Gugustinette]

This was resolved with #204