Thanks in advance.
1 Like
Building assets.
From all those files you have in assets it creates JavaScript files, images, CSS and more and sorts them into appropriate sub folders in priv/static.
6 Likes
Thanks for the reply.
can’t I do this myself?
This seems so dispenseable and redundant, I am trying to minimize third party packages as much as possible.
Yes, you can, but it will probably require a lot of work, and that after any change you do to your assets.
And even though I generally share the opinion to reduce runtime dependencies to a reasonable amount, I’m less strict with dev-time dependencies. And webpack is not there anymore at runtime. It builds your assets once and then is gone from your final artifacts.
5 Likes
If you don’t have a lot of client-side JS and CSS, you can skip webpack entirely.
See this guy.
5 Likes
If you don’t mind me asking, how will I be able to apply changes to the assets at runtime then ?
Why would one want to touch assets at runtime?
But well, webpack does nothing but recompiles on changes and writes the new artifacts to priv/static. You can do the same manually, just takes much more time…
1 Like
If you want to serve something that is dynamic at runtime, do not put it as part of your assets pipeline, instead just serve it from your controller
I recommend studying the whole thing INCLUDING the problems you must solve yourself without an existing toolchain in place.
A complex but well-known (and most importantly well-maintained) solution is superior
2 Likes
I have done some research and the primary function of webpack seems to be resolving the dependencies in the code, such as require statements, in the case of having multiple javascript files that import code from one another. So, will it be despicable if I am not going to import code from a file to another ?
This is what I read
It depends, as already explained above. For a web project you will want to keep webpack for sure.
If you are building an API, and don’t have any static assets then you can manage to go without it, just start your Phoenix project with:
mix phx.new myproject --no-webpack --no-html --no-dashboard --no-gettext --no-ecto
or don’t use Phoenix at all
mix new --sup myproject
All that phoenix does on project init is to create a simple, minimal, webpack build script, and then at runtime in dev environment it starts a node process (configured in the watchers IIRC) to run webpack in watch mode and rebuild your JS when you change code. That’s it.
So if you want to build your JS or CSS with another strategy, or just link static assets, feel free to remove it. It’s safe and phoenix does not care (besides the watcher erroring if you do not remove the config). I use rollup for most of my JS projects, so I generally use rollup instead of webpack in my phoenix projects/demos. Webpack is by no means mandatory.
That being said, the default webpack setup is very simple and is a pretty good base to build a JS app with ES6+ modern syntax that will be understood by most browsers. And why would you modify assets at runtime?
1 Like
I beg to differ. If you throw away the webpack.config.js file, can you recreate it’s content/functionality from scratch within an hour, using nothing but the official webpack manual? I know I can’t.
Within an hour I am not sure, that is why I rather use rollup 
But why would you do that? The default webpack config works out of the box. Do you also delete the default phoenix endpoint module to rewrite it from scratch? Though I would call it simple too, as in “simple to read and guess what it does”. Not “simple to write”.
I don’t but I think I can, maybe barely. Also they are different; endpoint.ex is source, webpack.config.js config. You really don’t need ot rewrite endpoint.ex, but sometimes you do want to rewrite webpack.config.js. For example I have a simple static site that uses a few npm packages and tailwindcss. I wanted to write webpack.config.js from scratch. That was a major struggle.
