First look at snowpack

Today is another Red Hat Day of Learning. A while ago I heard about snowpack, a new contender for the trusty old webpack to build modern web projects. Today I finally managed to take a quick look at it.

Even with webpack --watch one often needs to wait several seconds up to half a minute with some larger cockpit pages, so the promised split-second builds certainly sound attractive. At first sight it also makes more opinionated choices about sensible defaults, so that one hopefully does not have to write such a wall of boilerplate.

Hello world

I set up a playground repository, followed the getting started tutorial, and had my first working hello world within 15 minutes or so.

Then I quickly moved on to the snowpack React tutorial, updated my playground, and was very pleased – up to that point this Just Works™ without a single line of snowpack configuration! That is certainly a big plus.

$ npm run start

  http://localhost:8080 •
  Server started.

▼ Console

[snowpack] Hint: run "snowpack init" to create a project config file. Using defaults...
[snowpack] ! building dependencies...
[snowpack] ✔ dependencies ready! [6.39s]
[snowpack] File changed...

(Note: The real terminal output is colored)

The initial build takes a bit, but as promised, any further change to my code is done in a not-noticeable time, and the browser automatically updates to the new code.

Configuration only came into play when organizing the project directory to put the source code into src/, but one could do that with a three-liner (however, I kept the snowpack init template).

Cockpit page, take #1

A standalone web app is nice, but my roots are in the Cockpit project, so I was eager to see if snowpack works with that at all. Due to the way cockpit works, pages have to be served through cockpit’s own web server, so snowpack’s on-the-fly “dev” server does not work. So for that we need to use the snowpack build mode, with --watch for convenience, and that also worked surprisingly well and straightforward. I added a little demo for using the cockpit.file() API, similar to starter-kit.

Performance in this mode is similarly fast as with the dev server, one only loses the automatic browser refresh. The core idea of snowpack of not creating a bundle, but build and cache every file and npm library separately and let the browser load the modules by itself (every browser can do import these days) still holds.

Adding PatternFly

In cockpit, and in many other Red Hat projects we use the PatternFly web UI toolkit extensively, for getting a consistent, clean, desktop+mobile friendly and accessible design. Here I hit my first wall, as naïvely importing the library causes a lot of 404 errors for CSS and fonts not being found, because snowpack doesn’t copy the assets into the build directory. I am not the first one to run into this, but there is no official solution yet. So I came up with a workaround to salvage at least the CSS, and with this commit I got it working to a “good enough for a demo” and “yes, it uses PatternFly CSS” degree:

patternfly demo

babel.. or not

I thought the next step would have been babel, but it turns out that this is not really needed: snowpack can do JSX transformations natively, and for new projects one should really be able to stop worrying about some ancient crappy IE11 browsers – as long as one sticks to ES6, browsers should be able to just run the code without any transmogrification.


But eslint is of course important for enforcing clean code and spotting simple errors. So I first added a simple eslint configuration and then integrated it into snowpack, which was again pleasantly easy. It works as expected in watch mode:

▼ Console

[snowpack] ! building dependencies...
[snowpack] File changed...

▼ eslint

    11:7  error  Multiple spaces found before ''./index.css''  no-multi-spaces

  ✖ 1 problem (1 error, 0 warnings)
    1 error and 0 warnings potentially fixable with the `--fix` option.

Oops! I drop the superfluous space, and not a second later it’s all good:

▼ Console

[snowpack] ! building dependencies...
[snowpack] ✔ dependencies ready! [16.42s]
[snowpack] File changed... [x2]

▼ eslint

  ✓ Clean (5:17:36 PM)

This is certainly very cool, the same would have taken much longer with webpack.

Cockpit with PatternFly

Next step was to rebase the above “Cockpit hello world” to new master with PatternFly (commit), but here I hit a rather hard wall: snowpack puts the individually built files into paths that follow the npm module names, e.g. ../snowpack-playground/_snowpack/pkg/@patternfly/react-core.js. It turns out that cockpit-ws refuses file paths with @, so that’s a bug that we have to fix in cockpit first. Normally it uses @ to separate remote host channels from the path on the remote side, but this conflicts.

More advanced stuff

The above were more or less the “simple, obvious, and basic” things. Cockpit’s build system is a lot more complex than that, for example we have a webpack plugin for building translation js files from gettext po files, or some “interesting” (read: hackish) rules for adjusting font paths in the built CSS, all of which would need to be ported to snowpack. It does have a reasonable looking plugin API, but I ran out of time for these.

What I still did try however, was to use SASS files. There is an official snowpack sass plugin which uses the dart sass npm module. I tried to turn src/index.css into a proper .scss and adjust the import accordingly, but it seems this went entirely ignored by the build, and I have no idea why. This would need a more in-depth debugging session.

We don’t even care about that in Cockpit, we use our own loader that uses the packaged CLI sass for portability/licensing reasons. So maybe porting that would work better, but I haven’t looked into the snowpack equivalent of a webpack loader at all.

Finally, this is exclusively for development mode – for releases/production we still need to generate bundles, as cockpit-ws does not support HTTP/2 and thus browser performance would suck with lots of little files. For that purpose, snowpack has a webpack module which would be used for production builds only. At this point I have zero experience with it, and how easy/difficult it would be to integrate.


The two main stumbling blocks above (paths with @ and broken sass) certainly seem fixable, and then it is a very interesting alternative for new starter-kit derived projects.

For cockpit itself it seems still a bit immature, and we still have too much old baggage and technical debt to consider a switch now. I think efforts are better spent with optimizing the “webpack watch” workflow and avoiding redundant webpack invocations between CI machines and developers altogether.