-
Notifications
You must be signed in to change notification settings - Fork 2.9k
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Phoenix digest does not work with automatically generated webpack chunks #2996
Comments
After many of my experiences on front-end with Rails framework as well. I am wondering if we should be even generating digests inside phoenix to be honest. We could leave it up to webpack/bunch/... instead to generate the digest file. I think it would avoid us re-inventing parts of the wheel. e.g. being able to read something like https://www.npmjs.com/package/webpack-manifest-plugin ; I am also curious if it would work for this case. @chengyin you have any experience in the front-end side of this for dynamic imports? |
Hi @AlexRiedler, To your point, Webpack certainly prefers to manage all static assets for production usage. For dynamic importing specifically, Webpack requires knowledge about the chunk being imported therefore it must manage chunk generation for the imported piece. I think your idea works:
The lack of responses here makes me wonder if this is the right place for this discussion? |
@chengyin I think its the right place for discussion, I would be willing to put in the effort to move this forward if others think it makes sense to pull it out. I am just not sure if there is any argument to keep it in (maybe there is something I am not thinking about). I also am on the |
I've been experiencing exactly that problem recently, love your idea! |
okay, looking into this more; if we take the npm plugin I gave ; and work around the paths a bit I can actually get it to work with the existing setup weirdly enough (and make it not collide); basically supporting both systems depending on which one you want (which means we can defer whether to remove this from pheonix). Let me try to build an npm package :D |
Code splitting is a complex topic and entirely coupled to the build tool, so I don't think it's something we can or should handle on our side digest wise. I also don't feel we should drop our digester in favor of a webpack setup. While we ship with webpack by default, our digester is build-tool agnostic, which makes things like |
Unfortunate. I guess it makes for a good blog post then! |
@chengyin @happysalada (sorry chris) On my example project https://github.com/AlexRiedler/my_project I have something that MOSTLY works, see commits: AlexRiedler/my_project@4e69c31 basically it uses the entrypoints of webpack to make it work, I am not sure if this works for the chunking in which you are referring to; but maybe? Otherwise we would need to write some better type of manifesting in a node module. Thoughts? |
Hi @AlexRiedler I think your approach of reading Webpack manifest could totally work. Perhaps Moreover, since the code-splitting is all handled by Webpack, the chunk files should be named as generated by Webpack compilation. In this sense, running For example, for the dynamic chunk MyProjects.b450b5a3.chunk.js In my case, with CRAs, I'm using a fork of react-scripts that provides predictable bundle names so we can use them with |
I just noticed (after seeing this a thousand times) that the there is a config cache_static_manifest: "priv/static/cache_manifest.json", Maybe, there's no need for a another helper (?) |
@hisapy The It looks like Webpack needs to handle this compilation entirely. I realize this thread of 1.5 years old. Have either of you evolved your approach to this? I have yet to find a comprehensive approach to Webpack + Phoenix w/ dynamic imports. |
Yeah, old thread ... I've been using a fork of react-scripts without any inconveniences as far as I can tell ... maybe the same approach can be used in non CRA apps. |
@chrismccord would you be open to considering a I'm having the same issue, and I'd love to be able to solve this with something as simple as:
config :my_app, MyApp.Endpoint,
cache_loader: Webpack.CacheLoader,
cache_manifest: 'priv/static/manifest.json' With this, Ps. In this scenario, we're not changing anything with the |
^ moved this conversation over to the https://groups.google.com/g/phoenix-core/c/XURqwE5tZE8/m/rjTC1aKqBAAJ |
Webpack supports code splitting with dynamic import out of box, which is very helpful for reducing SPA initial loading size.
However those automatically generated chunks are not digested properly. The original file are still used instead of the hash-named and gzipped ones since the references to chunks live in the JS files instead of the eex files.
I'm not 100% sure if this should be Phoenix's concern. However I think to an extend this is similar to #1936. I also haven't found a workaround.
I generated a sample Phoenix app to demonstrate this behavior: http://github.com/chengyin/webpack-code-splitting-phoenix
Environment
Elixir 1.6.6 (compiled with OTP 20)
The text was updated successfully, but these errors were encountered: