Sass without Webpack

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/

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.

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)

      // 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]',
      },

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

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.

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.

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.

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.

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.

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 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.

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.

Glad I could help you to stop wasting your time!