Sass without Webpack

[peerreynders]

@caiocaio

Is there any way to use Phoenix without having to spend an inordinate amount of time of time messing around with npm or should I give up now?

You can opt out of webpack with --no-webpack.

Opting out of npm is a bit more problematic because you then have to be responsible for including phoenix_html.js and phoenix.js.

Webpack isn’t an integral part of Phoenix but since Phoenix’s initial release it has included a bundler for convenience and to promote the use of modern modular JavaScript. Initially Phoenix included brunch as a low-maintenance option but webpack has become the defacto standard with the React and Vue community, so Phoenix 1.4 switched to webpack due to popular demand. But nobody is forced to use webpack.

The Great Bundler Debate

Phoenix 1.4 ships with webpack - but that doesn’t mean you are stuck with it (but there certainly are reasons to stick with it). If bundling puzzles you have a look at Modern JavaScript Explained For Dinosaurs. Apart from all the other benefits that bundling can give you - the one that sticks out the most for me is: Modules. Over the past years I’ve cooled on classes in general because of their typical association with mutability but some form of code organization is needed for any non-trivia…

And while SASS will probably remain the standard for complex projects there has been a noticable trend towards simply using modern CSS features like CSS custom properties and a handful of (Node.js powered) PostCSS plugins instead of full-blown SASS for more basic needs.

At the most basic level Phoenix will serve static assets out of

my_app/priv/static

What is picked up from that folder is governed by

my_app/lib/my_app_web/endpoint.ex

  plug Plug.Static,
    at: "/",
    from: :my_app,
    gzip: false,
    only: ~w(css fonts images js favicon.ico robots.txt)

This default configuration will only pick up the favicon.ico and robots.txt files and whatever files are in the css, fonts, images, js folders (Plug.Static Options).

Given that knowledge you should be able to take full control over the content that is being served.

The one disadvantage is that you won’t have the convenience of live reloading during development. That is why the frontend development assets are kept under

my_app/assets

The tooling there typically places any “refreshed” static assets under

my_app/assets/static

so that it can be copied over to

my_app/priv/static

when it is ready.

Phoenix starts the watch script to build the asset files with:

my_app/config/dev.exs

config :my_app, MyAppWeb.Endpoint,
  http: [port: 4000],
  debug_errors: true,
  code_reloader: true,
  check_origin: false,
  watchers: [
    node: [
      "node_modules/webpack/bin/webpack.js",
      "--mode",
      "development",
      "--watch-stdin",
      cd: Path.expand("../assets", __DIR__)
    ]
  ]

via that watchers entry (Phoenix.Endpoint Runtime configuration).

Little bit further down in that same dev.exs:

  live_reload: [
    patterns: [
      ~r"priv/static/.*(js|css|png|jpeg|jpg|gif|svg)$",
      ~r"priv/gettext/.*(po)$",
      ~r"lib/my_app_web/{live,views}/.*(ex)$",
      ~r"lib/my_app_web/templates/.*(eex)$"
    ]
  ]

Those patterns determine what files will trigger Phoenix.LiveReloader to force a refresh in your browser.

This information should be enough for you to put together a frontend development environment of your own preference.