build: assetfiles-without-hash

[eitjuh]

Caution:

I assume this hash is implemented to ensure a new file is loaded. It's important to check if caching is handled correctly with this fix. It might lead to new problems with caching, and needing hard refreshes and things like that.

Problem:

The current build is causing this error:
It is because we are loading https://app.emeris.com/assets/Asset.4782f5bd.js
which has this hash 4782f5bd inside the url

Solution:

As described in vitejs/vite#378
There is an easy way to remove this hash by adding:

      rollupOptions: {
        output: {
          entryFileNames: `assets/[name].js`,
          chunkFileNames: `assets/[name].js`,
          assetFileNames: `assets/[name].[ext]`,
        },
      },

which cleans up the hash from the files, and you can see my dist folder, with a clean Asset.js:

This means it won't fail to dynamically import these modules anymore.

[github-actions]

Visit the preview URL for this PR (updated for commit d15bffc):

https://emeris-app--pr1760-build-assetfiles-wit-8sj8dt1y.web.app

_{(expires Tue, 14 Jun 2022 12:10:56 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

[fl-y]

LGTM until Sentry error logs are tidied up.
Long thread here https://allinbits.slack.com/archives/C02TBMVAJDN/p1652087614472409

[Dawntraoz]

The hashes are important for the user to have the latest changes: https://stackoverflow.com/questions/59194365/webpack-4-hash-and-contenthash-and-chunkhash-when-to-use-which, otherwise the user will always see an old version if we have cache in place, and I think is a huge problem for us

[eitjuh]

The hashes are important for the user to have the latest changes: stackoverflow.com/questions/59194365/webpack-4-hash-and-contenthash-and-chunkhash-when-to-use-which, otherwise the user will always see an old version if we have cache in place, and I think is a huge problem for us

would this create a temporary solution?
instead of
https://app.emeris.com/assets/Asset.4782f5bd.js
we use
https://app.emeris.com/assets/Asset.js?v=4782f5bd

@Dawntraoz would this solve your concern? This way we could still have the import resolve well, and also update it with the new hash

[Dawntraoz]

would this create a temporary solution? instead of https://app.emeris.com/assets/Asset.4782f5bd.js we use https://app.emeris.com/assets/Asset.js?v=4782f5bd

@Dawntraoz would this solve your concern? This way we could still have the import resolve well, and also update it with the new hash

Of course, but guessing that the version should be one for build and not one for file (as it was wtih the chunkHash).