Thanks a lot for this

[happysalada]

I'll have a good look at it this weekend and tell you if I see anything that can be improved.

[happysalada]

So I tried your setup.

• You can add the function in the MyProjectWeb view macro to have it included in every view if you want. (just a thought)
• So I set up a similar thing that you had for my project, and I found there was some problems when I was using a different route than the default route. For exemple being on /b2e2f88e-449a-49ad-973e-47659582e482/factsheet webpack tries to load/b2e2f88e-449a-49ad-973e-47659582e482/my-chunk.js which is not there, since they are in the root. It might be a problem with my setup.
• I found that to use dynamic import there is another way (albeit, a little painful). You can use chunkFilename: 'js/[name].chunk.js', in output, then use the magic comment /* webpackChunkName: "my-chunk-name" */ and then just add another script tag in your html page<link rel="prefetch" href="<%= static_path(@conn, "/js/my-chunk-name.chunk.js") %>"> Then it works. The obvious problem with that is that you need to add a separate script tag for all your chunks.
• you probably know this, but using an async await in the initialize function enables several dynamic imports.

  
  const initializeApp = async () => {
  const {default: dynamic = await import(/* webpackChunkName: "dynamic */ /* webpackPrefetch: true */ "./dynamic")
  dynamic()
  }

document.addEventListener("DOMContentLoaded", initializeApp, false)

Last but not least, a big thank you for getting me started on this. I needed a push to figure this out and your repo was a lot of help!

Some unrelated stuff that you might be interested in:
A couple of comments
- why do you use alpine 3.6 explicitely in the dockerfile when elixir 1.7.2 is using alpine 3.8 ?
- apk update, just updates the package repository reference. I think you want to run `apk upgrade` to upgrade the packages.
- I don't think you want to have

CMD ["/app/bin/my_project", "foreground"] ENTRYPOINT ["/app/bin/my_project"]

in your docker file.
You would either want

ENTRYPOINT ["/app/bin/my_project"] CMD ["foreground"]

or just

CMD ["/app/bin/my_project", "foreground"]

The advantages of the latter being that you can run other scripts on your container
- be careful with the watcher you set (on phoenix master it uses webpack with `--watch-stdin`. If you don't have this, when you ctr-c you have node ghost processes persisting. (a detail, I'm just saying that because it took me a long time to find)

Some questions
- I've never had to run a cluster of nodes, is that why you define the EPMD and BEAM port, to connect nodes together?
- I haven't used edeliver. I didn't know you could use it with docker. Are you using edeliver to copy the image onto the server? Why not do a scp then run the image with docker-swarm? (just curious)

[AlexRiedler]

Webpack

• Nice about the view macro, good idea!
• The loading directory could be something to do with how I have the basedir setup for entry; I had to play a bit with the beginning of urls to make it what I wanted it to look like (without the ./) but maybe it had a bad side effect. I should probably test this.

I found that to use dynamic import there is another way (albeit, a little painful)...

• The selecting of chunks on a page feels pretty annoying cause then you have to know exactly which page needs which chunks; feels like it slightly destroys the purpose (also now long term caching is broken)
• I was trying to get to the world where I would never need to use phx.digest either, and just let webpack do that part as well

you probably know this, but using an async await in the initialize function enables several dynamic imports.

Nope didn't know this at all, more of a backend developer then front-end. Good to know!

Docker Stuff

A lot of the docker stuff is an experiment; I actually have a branch (WIP) to the docker stuff that fixes a lot of the issues that you outlined above (particularly the entrypoint and cmd). See https://github.com/AlexRiedler/my_project/tree/docker-releases

The docker stuff was based off another repo example on edeliver/issues/121 ; some of which felt weird to me in general. edeliver currently doesn't support docker. However, you can build locally in docker to avoid having a dedicated build server, then just edeliver to staging and production.

I've never had to run a cluster of nodes, is that why you define the EPMD and BEAM port, to connect nodes together?

yeah this is so you can remotely connect to the erlang vm if necessary for both management and clustering

THANKS FOR THE WRITE UP

Glad I could be of service; and Thanks for Reaching out! I'll probably post about my findings above if I can avoid the issue.

[happysalada]

On the webpack stuff.

• I think I will give it one more go in the near future. What I am mainly not satisfied about is how I split my chunks. I currently have one huge vendor chunk, and that's just not great. I would ideally like to split it even further. I'll update with my findings here. I will try your way though.
• I'm interested if you do a writeup, I think anybody with a production app will be able to benefit from this.

On the clustering stuff.

• Do you use kubernetes? Or do you deploy several machines in production and cluster the with something like cluster_lib? I have never had to do this before (as I only have one machine in production yet), so anything around this I'm interested! (I personally still use docker-swarm but planning on moving to kubernetes before the end of the year)

A couple of comments on the docker stuff

• I install yarn usually in the image, it significantly speeds up the install time (for a good docker image reference, have a look at https://github.com/bitwalker/distillery/blob/master/docs/guides/working_with_docker.md)
• custom tasks has been changed in the latest version of distillery (2.0.X), I haven't made the upgrade yet, but the old way doesn't work anymore.

[AlexRiedler]

Webpack

• You should be able to split across all your individual views, maybe even to the component level; I would have to look into chunks more though.

Clustering

• Currently not doing clustering in production

Docker

• OOoo didn't know distillery had a write up in their docs now about working with docker, good to know.
• I assume you are talking about the hooks? I have them fixed (pushed locally this morning)

[happysalada]

Okay, I gave this a real go, but couldn't make it work.

I used

optimization: {
    splitChunks: {
      chunks: ({name}) => !name || !name.includes('admin'),
    }
  },

which is just a way to tell it to split chunks on all except the ones where the name includes "admin". I can see the chunks being split up

update  [emitted]         update
                                                                 1.chunk.js    61.8 KiB                                                                   1  [emitted]
                                                                 2.chunk.js    59.8 KiB

however they don't appear in the manifest, only my entrypoints name do. of course when I try to load the page, it doesn't display any error, but it doesn't show me the things that the js is supposed to load as well. looking at the doc of the webpack manifest plugin publicPath is supposed to be a string, so that's what I used (just "/") I couldn't find the merge option, so I didn't use it. Appart from that, my setup is very similar to yours. not really sure what is the problem.

[AlexRiedler]

You shouldn't need the chunks in the manifest because they will be dynamically loaded by the correct path inside the javascript that included them.

Although when I am testing here, it seems named dynamic chunks also get put into the manifest.json.

import(/* webpackChunkName: "dynamic" */ "./dynamic").then(({ default: dynamic }) => {
  dynamic();
});

I really don't understand chunk optimization stuff, I could never get it to work as I thought it would.

[happysalada]

yes correct. The limitation is that you can't name all of your chunks. The chunks that you name under imports are all the async chunks, if you want to name the split from the initial chunks, I don't know how to do it. The problem is then that webpack tries to load assets with a relative paths (when not on the default route) and doesn't find them. So I think the maximum that can be done here, is to split only async chunks, then you can probably use your webpack setup.

I would add to that as well, that to preserve caching, you have to include the setting to keep the runtime in a single chunk. https://webpack.js.org/guides/caching/