chore: generate CSS hash using the filename
#16740
Closing issue
Describe the problem
Svelte adds svelte-xyz123 hashes to CSS rules and the corresponding elements, so that styles don't affect other components. This hash is based on the contents of the <style> block.
This works but it means that the hashes change frequently between deployments. It might be better to default to hashing based on the filename instead. I think the reason we didn't originally do this was that not all project setups made the filename available to the compiler, but now that most people are using vite-plugin-svelte that's probably not an issue any more.
Describe the proposed solution
Update this...
...to this:
cssHash: fun(({ css, filename, hash }) => {
return `svelte-${hash(filename ?? css)}`;
}),Importance
nice to have
Pull request
Closes #16636, alternative to #16697.
Before submitting the PR, please make sure you do the following
- It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
- Prefix your PR title with
feat:,fix:,chore:, ordocs:. - This message body should clearly illustrate what problems it solves.
- Ideally, include a test that fails without this PR but passes with it.
- If this PR changes code within
packages/svelte/src, add a changeset (npx changeset).
Tests and linting
- Run the tests with
pnpm testand lint the project withpnpm lint
Info
![changeset-bot[bot]](https://avatars.githubusercontent.com/in/28616?v=4)
🦋 Changeset detected
Latest commit: 8ee268f
The changes in this PR will be included in the next version bump.
This PR includes changesets to release 1 package
| Name | Type |
|---|---|
| svelte | Patch |
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
![svelte-docs-bot[bot]](https://avatars.githubusercontent.com/u/23617963?v=4)
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?v=4)
pnpm add https://pkg.pr.new/svelte@16740
Ah. This fails because filename is often absolute, meaning it differs based on where it runs. We don't have a good way to enforce project-relative filenames, and making builds non-deterministic seems bad. I'm now therefore of the opinion that we shouldn't make this change.
What if we use the closest package.json to determine the project's root directory, and then replace any backslashes with slashes (so windows doesn't differ from everything else)?
Oh actually, we have rootDir available... maybe we can just use that. Taking a run at it