# Sass without Webpack

**URL:** <https://forum.elixirforum.com/t/sass-without-webpack/25901>\
**Category:** Questions\
**Tags:** phoenix, webpack, troubleshooting\
**Created:** [October 7, 2019, 8:43pm UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901 "2019-10-07T20:43:23Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![caiocaio](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/caiocaio/32/16962_2.png) [@caiocaio](https://forum.elixirforum.com/u/caiocaio)\
**Post date:** [October 7, 2019, 8:43pm UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901/1 "2019-10-07T20:43:23Z")

</div>

Hi,

I wanted to get SASS working with Phoenix, but I just wasted my entire morning trying unsuccessfully to resolve npm dependencies (ie webpack 4.4 requires a package that requires webpack 4.36, and every attempt to fix is slow as molasses). 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?

---

<div class="post-metadata">

**Author:** ![outlog](https://forum.elixirforum.com/letter_avatar_proxy/v4/letter/o/c0e974/32.png) [@outlog](https://forum.elixirforum.com/u/outlog)\
**Post date:** [October 7, 2019, 8:47pm UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901/2 "2019-10-07T20:47:35Z")

</div>

this one worked fine for me for adding Bulma over the weekend: [https://phxroad.com/guides/add-bulma-fontawesome-and-sass-to-phoenix-using-webpack/](https://phxroad.com/guides/add-bulma-fontawesome-and-sass-to-phoenix-using-webpack/)

---

<div class="post-metadata">

**Author:** ![kokolegorille](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/kokolegorille/32/4784_2.png) [@kokolegorille](https://forum.elixirforum.com/u/kokolegorille)\
**Post date:** [October 7, 2019, 8:50pm UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901/3 "2019-10-07T20:50:01Z")

</div>

Hello and welcome to the forum…

It’s mostly due to the ever moving js world. There is a post by @peerreynders here that explains how to procede with babel config. Don’t miss the **ncu -u** part, which is really cool tip to update your npm dependencies.

> [@Connecting React with Phoenix](https://forum.elixirforum.com/t/connecting-react-with-phoenix/23935/22):
>
> For future reference: $ mix phx.new react\_demo --no-ecto \* creating react\_demo/config/config.exs ... \* creating react\_demo/assets/static/robots.txt Fetch and install dependencies? [Yn] Y \* running mix deps.get \* running cd assets && npm install && node node\_modules/webpack/bin/webpack.js --mode development \* running mix deps.compile We are almost there! The following steps are missing: $ cd react\_demo Start your Phoenix app with: $ mix phx.server You can also run your app inside …

Don’t forget to add node-sass and sass-loader.

A good start would be to show part of your package.json and webpack.config.js.

These are rules I am using for sass, fonts, images… (in webpack.config.js)

```javascript
      // Load stylesheets
      {
        test: /\.(css|scss)$/,
        use: [
          MiniCssExtractPlugin.loader,
          'css-loader',
          'sass-loader',
        ]
      },
      // Load images
      {
        test: /\.(png|svg|jpe?g|gif)(\?.*$|$)/,
        loader: 'url-loader?limit=10000',
      },
      // Load fonts
      {
        test: /\.woff(2)?(\?v=[0-9]\.[0-9]\.[0-9])?(\?.*$|$)/,
        use: 'url-loader?&limit=10000&name=/fonts/[name].[ext]',
      },
      {
        test: /\.(eot|ttf|otf)?(\?.*$|$)/,
        loader: 'file-loader?&limit=10000&name=/fonts/[name].[ext]',
      },

```

---

<div class="post-metadata">

**Author:** ![l-vincent-l](https://forum.elixirforum.com/letter_avatar_proxy/v4/letter/l/e19adc/32.png) [@l-vincent-l](https://forum.elixirforum.com/u/l-vincent-l)\
**Post date:** [October 9, 2019, 8:19am UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901/4 "2019-10-09T08:19:14Z")

</div>

I started something to do that it’s here, it uses sass-c [GitHub - l-vincent-l/elixir-sass-reloader: Add this module to compile your sass file without webpack · GitHub](https://github.com/l-vincent-l/elixir-sass-reloader)

---

<div class="post-metadata">

**Author:** ![peerreynders](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/peerreynders/32/5826_2.png) [@peerreynders](https://forum.elixirforum.com/u/peerreynders)\
**Post date:** [October 9, 2019, 1:36pm UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901/5 "2019-10-09T13:36:26Z")

</div>

> [@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](https://hexdocs.pm/phoenix/phoenix_mix_tasks.html#phoenix-specific-mix-tasks) 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`](https://github.com/phoenixframework/phoenix_html/blob/master/priv/static/phoenix_html.js) and [`phoenix.js`](https://hexdocs.pm/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](https://flaviocopes.com/es-modules/). Initially Phoenix included [`brunch`](https://brunch.io/) 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](https://forum.elixirforum.com/t/the-great-bundler-debate/18330):
>
> Phoenix 1.4 ships with [webpack](https://webpack.js.org/) - 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](https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70). 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](https://medium.com/@im.simonecorsi/moving-from-sass-to-postcss-why-what-and-how-f68b1bc760dc) towards simply using modern CSS features like [CSS custom properties](https://developer.mozilla.org/en-US/docs/Web/CSS/--*) and a handful of (Node.js powered) [PostCSS](https://medium.com/heresy-dev/getting-started-with-postcss-a-quick-guide-for-sass-users-90c8b675d5f4) plugins instead of full-blown SASS for more basic needs.

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

```plaintext
my_app/priv/static

```

What is picked up from that folder is governed by

```plaintext
my_app/lib/my_app_web/endpoint.ex

```

```elixir
  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](https://hexdocs.pm/plug/Plug.Static.html#module-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

```plaintext
my_app/assets

```

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

```plaintext
my_app/assets/static

```

so that it can be copied over to

```plaintext
my_app/priv/static

```

when it is ready.

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

```plaintext
my_app/config/dev.exs

```

```elixir
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](https://hexdocs.pm/phoenix/Phoenix.Endpoint.html#module-runtime-configuration)).

Little bit further down in that same `dev.exs`:

```config
  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`](https://hexdocs.pm/phoenix_live_reload/Phoenix.LiveReloader.html) 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.

---

<div class="post-metadata">

**Author:** ![LostKobrakai](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/lostkobrakai/32/3072_2.png) [@LostKobrakai](https://forum.elixirforum.com/u/LostKobrakai)\
**Post date:** [October 9, 2019, 1:51pm UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901/6 "2019-10-09T13:51:58Z")

</div>

> [@peerreynders](#):
>
> 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
> 
> ```elixir
> my_app/assets
> 
> ```
> 
> The tooling there typically places any “refreshed” static assets under
> 
> ```elixir
> my_app/assets/static
> 
> ```
> 
> so that it can be copied over to
> 
> ```elixir
> my_app/priv/static
> 
> ```
> 
> when it is ready.

That’s not completely correct.

`config :my_app, MyAppWeb.Endpoint, watchers: […]` does only handle that e.g. the webpack watcher is started when phoenix is serving the endpoint. This is completely unrelated to live reloading, which only works based on the wildcards listed in `:live_reload`.

Any external tool, which can put/update files in `priv/static` will trigger live reloads.

---

<div class="post-metadata">

**Author:** ![peerreynders](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/peerreynders/32/5826_2.png) [@peerreynders](https://forum.elixirforum.com/u/peerreynders)\
**Post date:** [October 9, 2019, 1:59pm UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901/7 "2019-10-09T13:59:34Z")

</div>

> [@LostKobrakai](#):
>
> This is completely unrelated to live reloading,

It is unrelated to `Phoenix.LiveReload` - but it it is an integral part to the _live reloading development cycle_.

`Phoenix.LiveReload` won’t have anything to do (frontend asset -wise) unless files in those directories are changed - (watching and) updating the static asset files is the responsibility of the script that is started by `watchers` - so the `watchers` configuration is an integral part of the _live reloading development cycle_ even if that is part of the `Phoenix.Endpoint` rather than the `Phoenix.LiveReload` configuration.

---

<div class="post-metadata">

**Author:** ![LostKobrakai](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/lostkobrakai/32/3072_2.png) [@LostKobrakai](https://forum.elixirforum.com/u/LostKobrakai)\
**Post date:** [October 9, 2019, 2:20pm UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901/8 "2019-10-09T14:20:48Z")

</div>

> [@peerreynders](#):
>
> but it it is an integral part to the _live reloading development cycle_ .

Not really. I could just as well edit a `style.css` file manually in `priv/static` and it would be live reloaded. A watcher is only needed if there’s a compilation step to be done when source files are edited. For anyone working directly with the to-be-deployed assets this can be skipped completely.

---

<div class="post-metadata">

**Author:** ![peerreynders](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/peerreynders/32/5826_2.png) [@peerreynders](https://forum.elixirforum.com/u/peerreynders)\
**Post date:** [October 9, 2019, 3:37pm UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901/9 "2019-10-09T15:37:03Z")

</div>

> [@LostKobrakai](#):
>
> For anyone working directly with the to-be-deployed assets this can be skipped completely.

The OP is talking about using Sass.

In that situation the file edited would be an `.scss` or `.sass` file. A recurring theme in _top 10 web development mistakes_ [lists](https://www.airpair.com/node.js/posts/top-10-mistakes-node-developers-make#1-2-automatic-browser-refresh) is not using _automatic browser refresh_ when _any_ of the development assets are being updated - that is what the `watchers` configuration is for.

A watcher script preparing (and copying) frontend assets is an essential ingredient in a modern web development workflow that aims to automate browser refreshes for development.

If your aim is to trigger an automatic browser refresh (i.e. _live reload development_) when any `.scss` or `.sass` file is modified then you need to configure `watchers`.

---

<div class="post-metadata">

**Author:** ![LostKobrakai](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/lostkobrakai/32/3072_2.png) [@LostKobrakai](https://forum.elixirforum.com/u/LostKobrakai)\
**Post date:** [October 9, 2019, 4:04pm UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901/10 "2019-10-09T16:04:49Z")

</div>

I’m not disputing that this is the better case, but I still doubt that insisting on the need on some kind of watcher controlled by phoenix is the only way to go. In the past I’ve had great success with tools like CodeKit, which bundles all the dirty details of compiling source files in an easy to use desktop app. Sure this is not great for workflows involving CI/CD, but such applications can still be viable solutions outside of those constraints. Not everybody needs/uses a project building workflow with all the bells and whistles. When aware of the potential downsides it can be perfectly fine to opt for simpler solutions.

---

<div class="post-metadata">

**Author:** ![peerreynders](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/peerreynders/32/5826_2.png) [@peerreynders](https://forum.elixirforum.com/u/peerreynders)\
**Post date:** [October 9, 2019, 7:25pm UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901/12 "2019-10-09T19:25:42Z")

</div>

Glad I could help you to stop wasting your time!

---

<div class="post-metadata">

**Author:** ![dimitarvp](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/dimitarvp/32/38664_2.png) [@dimitarvp](https://forum.elixirforum.com/u/dimitarvp)\
**Post date:** [October 9, 2019, 10:26pm UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901/13 "2019-10-09T22:26:54Z")

</div>

> [@caiocaio](#):
>
> I think I’m done with my Phoenix/Elixir experiment.

Meaning? Truthfully, the JS part of the stack is a huge pain no matter the backend framework… I’ve tried web frameworks in 5 languages and none were really easing the troubles of the JS tooling.

---

<div class="post-metadata">

**Author:** ![jdumont](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/jdumont/32/2353_2.png) [@jdumont](https://forum.elixirforum.com/u/jdumont)\
**Post date:** [October 10, 2019, 12:54pm UTC](https://forum.elixirforum.com/t/sass-without-webpack/25901/14 "2019-10-10T12:54:28Z")

</div>

The issues you’re having aren’t with Elixir, Phoenix.

I personally don’t use Webpack or any other JS-based build tool exactly because of the issues you’ve encountered. I use a mixture of Rust CLI tools and believe it or not, Make. These integrate well with Phoenix as @peerreynders explained to you.

The issues you’ve encountered are with front-end development in general. JS and the build tools that often come with it are a fact of life unless you can forego JS and other static asset compilation entirely.

Coming to a forum, asking a question and having a number of people write out extremely thorough, clear and well researched answers — that are better than the docs in this case! — only to throw it back in their face with an arrogant, knee-jerk of a response is not cool at all.

If your “one-man webdev business” is going to survive, then you’ll need to learn about how to be nice to people, not compile your Sass without Webpack.