Hey everyone, yesterday I have played around with Vite.js and it feels really nice for frontend dev in Phoenix. The setup is currently a bit involved, so I have documented the process here:
Please share your feedback if there are some questions / suggestions!
Hi, I switched from Snowpack to Vite recently, and it works great on my production. I’d like to provide my setup here which is, I think, the easiest way.
--- a/assets/package.json
+++ b/assets/package.json
@@ -3,8 +3,8 @@
"scripts": {
+ "build": "vite build",
+ "watch": "vite build --watch --minify false --emptyOutDir false --clearScreen false --mode development"
},
"devDependencies": {
+ "vite": "^2.2.4"
}
}
--- /dev/null
+++ b/assets/vite.config.js
@@ -0,0 +1,19 @@
+export default {
+ publicDir: "./static",
+ build: {
+ target: "es2018",
+ minify: true,
+ outDir: "../priv/static",
+ emptyOutDir: true,
+ rollupOptions: {
+ input: ["js/app.js", "css/app.css"],
+ output: {
+ entryFileNames: "js/[name].js",
+ chunkFileNames: "js/[name].js",
+ assetFileNames: "[ext]/[name][extname]"
+ }
+ },
+ assetsInlineLimit: 0
+ }
+}
--- a/config/dev.exs
+++ b/config/dev.exs
@@ -23,7 +23,7 @@ config :fset, FsetWeb.Endpoint,
watchers: [
- node: ["whatever", "ever", cd: Path.expand("../assets", __DIR__)]
+ yarn: ["run", "watch", cd: Path.expand("../assets", __DIR__)]
]
--- a/Dockerfile
+++ b/Dockerfile
@@ -27,7 +27,7 @@ ENV NODE_ENV=production
COPY lib lib
COPY priv priv
COPY assets assets
+RUN yarn --cwd ./assets run build
RUN mix phx.digest
Just wondering why you decided to move from snowpack to vite? They both seem pretty similar… I got snowpack to work with a fresh Phoenix/LiveView project but have not experimented with vite yet.
This may not be a good answer but my reason was not related to features comparison. I ran into infinite build problem with snowpack + phoenix live reload, and I can’t fix it within an hour, so I decided “lets change build tool and get rid of both problem and solution seeking altogether”
Update my setup above (changed 1 line, everything stays the same), use chokidar directly (vite build uses it under the hood anyway) for better control what to watch.
+ "watch": "chokidar js css -c 'vite build --minify false --emptyOutDir false --clearScreen false --mode development'"
Hi, is your part 2/tailwind integration available?
Hey @maz, I’ll try to finish it before the end of this week 
Hi @50kudos! I tried Vite today for the first time with Phoenix 1.6 and your response was really helpful. In the end, I had to do a little bit more work, but It seems everything is working as expected. Here’s my setup…
package.json
{
"repository": {},
"description": " ",
"scripts": {
"build": "vite build",
"watch": "vite build --watch --minify false --emptyOutDir false --clearScreen false --mode development"
},
"dependencies": {
"@popperjs/core": "^2.10.1",
"bootstrap": "^5.1.1",
"phoenix": "file:../deps/phoenix",
"phoenix_html": "file:../deps/phoenix_html",
"phoenix_live_view": "file:../deps/phoenix_live_view"
},
"devDependencies": {
"sass": "^1.42.1",
"vite": "^2.5.10"
}
}
Fixes problems with import resolution for “phoenix”, “phoenix_html” and “phoenix_live_view” and includes support for Sass.
vite.config.js
export default {
publicDir: "./static",
build: {
target: "es2018",
minify: true,
outDir: "../priv/static",
emptyOutDir: true,
assetsInlineLimit: 0,
rollupOptions: {
input: ["js/app.js", "css/app.scss"],
output: {
entryFileNames: "js/[name].js",
chunkFileNames: "js/[name].js",
assetFileNames: "[ext]/[name][extname]"
}
},
}
}
dev.exs
config :my_app, MyAppWeb.Endpoint,
http: [ip: {127, 0, 0, 1}, port: 4000],
debug_errors: true,
code_reloader: true,
check_origin: false,
watchers: [
npm: ["run", "watch", cd: Path.expand("../assets", __DIR__)]
]
mix.exs
"assets.deploy": ["cmd --cd assets npm run build", "phx.digest"]
endpoint.ex
plug Plug.Static,
at: "/",
from: :my_app,
gzip: false,
only: ~w(css js fonts images favicon.ico robots.txt)
Differs from the default esbuild config which outputs directly to
priv/static/assets.
root.html.heex
<link phx-track-static rel="stylesheet" href={Routes.static_path(@conn, "/css/app.css")}/>
<script defer phx-track-static type="module" src={Routes.static_path(@conn, "/js/app.js")}></script>
Updates public path and adds
type="module"to properly load the exposed javascript module.
PS.: It seems that Vite supports older browsers with a plugin but I didn’t seem to work for me.
Bonus: If you are using VS Code with ElixirLS and your *.heex files are not properly highlighted you can add the following setting to your user config: "files.associations": {"*.heex": "html-eex" }
Thanks for the detailed gist @thiagomajesk.
Observed that you have setup the latest bootstrap. It would have been nicer if you showed your app.scss and app.js as well. Does the bootstrap Javascript work normally with LiveView? For alpine, you need extra setup for it to work smoothly with LiveView. Does Bootstrap also need any extra configuration?
Hi @cvkmohan! Everything should work as expected for both app.scss and app.js, you just need to import your files as usual (eg: @import "bootstrap" and import 'bootstrap').
About LiveView, I haven’t tested how it interacts with other Javascript libraries. I can’t recall having problems with Bootstrap the last time I used it, but this was over a year ago. The problems you’re likely to encounter tend to be related to code initialization and keeping state, since LV will not reload the page.
I know there are some questions on the forum about this, perhaps you should take a look and see if you find better content on the subject there. Since I’m not actively trying to use LV with Alpine and Bootstrap I’m not the best person to answer that.
Early on, I had the idea that I wanted separate CSS files for separate pages of my app*, and as a result of that, found so much success in just decoupling the styling from the bundling altogether, running brew install sass/sass/sass on my dev box, and then feeling the glorious, glorious lifting of a burden when I deleted so many CSS-based plugins from package.json and webpack.config.
Then Phoenix migrated everything over to esbuild, and rocky takeoff notwithstanding, I have everything running smoothly and snappily now.
# config/dev.exs
watchers: [
sass: ~w[--watch --no-source-map assets/css/:priv/static/css],
esbuild: {Esbuild, :install_and_run, [:default, ~w(--watch)]}
]
I’ve also got a mix task for wrapping all of my assets up in a nice, self-contained digest when it’s deploy time. I call it assets.deploy
defmodule Mix.Tasks.Assets.Deploy do
use Mix.Task
@shortdoc "Packages assets for the browser"
@moduledoc """
Packages assets for the browser.
If the `DEV_MODE` environment variable is set, will not minify the CSS and JS,
or create a sourcemap for either.
"""
def run(_args) do
dev_mode? = env("MIX_ENV") in [:dev, :test, nil]
shell! "rm -rf priv/static/*"
shell! "cp -R assets/static/* priv/static/"
cmd "sass assets/css/app.scss:priv/static/css/app.css" <> (unless dev_mode?, do: " --source-map", else: "")
cmd "mix esbuild default" <> (unless dev_mode?, do: " --minify --sourcemap", else: "")
unless dev_mode? do
cmd "mix phx.digest -o priv/digest"
shell! "rm -rf priv/static/*"
shell! "mv priv/digest/* priv/static/"
end
end
defp cmd(command, collectible \\ IO.stream(:stdio, :line)) when is_binary(command) do
[app | options] = String.split(command, ~r/\s+/)
cmd(app, options, collectible)
end
defp cmd(app, options, collectible) do
[app | options] |> IO.inspect
System.cmd(app, options, into: collectible)
end
defp shell!(command, opts \\ [into: IO.stream()]) do
command |> IO.inspect
System.shell(command, opts)
end
defp env(var), do: System.get_env(var)
end
(the cmd, shell!, and env patterns are brought over from my actual deployment-deploying task, sort of a bespoke take on Capistrano for publishing to gigalixir through its’ git endpoint… possibly from a tty box idk life’s wild sometimes. I call it giggitty. But I’m way off topic now!
EDIT: * I did, of course, realize the awful idea that would’ve been, and now roll all of my CSS, with the comparatively gigantic phoenix.css taffy monster beneath my app.scss file and everything, into one, huge, abomination.
Thanks so much for this. I was thinking of trying out a Vite based setup too, and you’ve done all the hard work for me.
Thanks a lot! I’m new to Elixir, your details were very helpful. 
In complement, this article was useful to me integrating vite.js with phoenix 1.6 | moroz.dev
Should we disable the esbuild used in Phoenix (with the watcher) to avoid conflict with Vite.js?
I finally managed to port another project using Webpack to Vite and I made some changes to my vite.config.js file. The main reason for those changes are:
import { defineConfig } from "vite";
export default defineConfig((command) => {
maybeCloseStdin(command)
return {
publicDir: "./static",
build: {
target: "es2018",
minify: true,
outDir: "../priv/static",
emptyOutDir: true,
assetsInlineLimit: 0,
rollupOptions: {
input: ["js/app.js", "css/app.scss"],
output: {
entryFileNames: "js/[name].js",
chunkFileNames: "js/[name].js",
assetFileNames: chunkAssets
},
}
}
}
})
/*
* Watches and closes stdin when the main process closes.
* This avoids zombie esbuild processes accumulating in the system.
*/
function maybeCloseStdin(command) {
if (command == "build") return
process.stdin.on("close", () => { process.exit(0) })
process.stdin.resume()
}
/*
* Maps asset chunks to their corresponding folder.
* Keys are regexes that match the file name and values should be a asset folder.
* This first match is always used, so make sure to put the most specific regex first.
*/
const assetChunkMappings = {
"\.webfonts/\.(woff2?|ttf|eot|svg)": "fonts/[name][extname]",
"\.(woff2?|ttf|eot)$": "fonts/[name][extname]"
}
function chunkAssets(info) {
return Object.entries(assetChunkMappings)
.filter(([key, _value]) => info.name.match(key))
.map(([_key, value]) => value)[0] || "[ext]/[name][extname]"
}
Just an important update on this solution:
If someone is having problems using it, just replace this line: export default defineConfig((command) with export default defineConfig(({command}). The destructuring syntax here is important because if not, the wrong object will be passed to maybeCloseStdin which will cause the vite build command to not exit properly, preventing other commands like mix phx.digest to execute correctly giving you lots of headaches in production 
.
I have an important update on this solution: It seems that there was some sort of regression and the provided solution to prevent zombie processes doesn’t work anymore (details here and here). If you are still having problems where Vite is leaving orphan processes behind, try changing your setup to use a wrapper script instead. The main idea is explained in the docs here: Port — Elixir v1.12.0-rc.0.
# mix.exs alias for asset deploy...
# If your deploy process uses docker you can simply use npx here.
# However, if your deploy machine state is persistent, call the binary from the node_modules directly instead.
"assets.deploy": ["cmd --cd assets npx vite build", "phx.digest"]
# dev.exs config watchers
# Call the Vite binary directly in development, which is the most common use-case.
# It's important to call the binary directly because the wrapper will terminate only the direct children.
# phoenix [server] -> node -> esbuild [vite] (works properly when terminated)
# If we call 'npx' here, another node process will be spawned and the process tree will become something like:
# phoenix [server] -> node -> node [npx] -> esbuild [vite] (won't be terminated properly)
# To understand it better, you can observe this problem by echoing the PID in the wrapper script and checking which process in the tree is actually being terminated.
watchers: [
"#{Path.expand("../assets/wrapper.sh", __DIR__)}": [
"node_modules/.bin/vite",
"build",
"--watch",
"--minify",
"false",
"--emptyOutDir",
"false",
"--clearScreen",
"false",
"--mode",
"development",
cd: Path.expand("../assets", __DIR__)
]
wrapper.sh
#!/usr/bin/env bash
# Start the program in the background
exec "$@" &
pid1=$!
# Silence warnings from here on
exec >/dev/null 2>&1
# Read from stdin in the background and
# kill running program when stdin closes
exec 0<&0 $(
while read; do :; done
kill -KILL $pid1
) &
pid2=$!
# Clean up
wait $pid1
ret=$?
kill -KILL $pid2
exit $ret
@thiagomajesk Any reason you went for vite build and then --watch it in dev mode? Default for dev would be just vite and with this you just have to make the assets available via the header through localhost e.g. phoenix-liveview-vite-demo/_preamble.html.heex at main · moroz/phoenix-liveview-vite-demo · GitHub
Would love to hear your opinion about it or if you just wanted to keep it closer to the deploy functionality?
best
denym_
Interesting take @denym. I’m not an expert on build tools but at first sight, I’d be wary of possible side-effects with vite hot reload. This might not be a problem at all, and if it’s working, go for it, less configuration is always better; in fact, this solution would make a nice integration lib (with the script tag replacement solution and all).
@thiagomajesk Just further followups on your approach:
@/some/path can’t be used and all imports in vue have to be relativeroutes.ex
With just those issues I can only recommend using a clean external vite project besides your phoenix backend. Especially when you use phoenix as api backend.
Just my 2 cents & best regards
denym_
I really like your solution and also used it.
Just one addition, as I struggled with it. The current solution will deleted files like robots.txt in /priv/static. If you need them, change emptyOutDir to emptyOutDir: false.
© Copyright Elixir Forum | Terms | Privacy & Cookies
