Snowpack: 4.0 and beyond

[drwpow]

👋🏻 Hello! Wanted to create an issue to provide a bit of a project update and what we have planned. First, some background:

Snowpack launched in Jun 2019 (over 2 years ago!). Since then, it’s had 3 major releases, a name change (originally @pika/web), 1.2+ million downloads from npm, over 18k stars on GitHub, and 300+ contributors. And the best part has been the community—seeing so many excited to push the web forward while simplifying tooling.

In that 2 years, a lot’s changed! For starters:

• Node.js shipped ESM support in core (2019)
• esbuild appears, providing an orders-of-magnitude-faster alternative to Babel for pure building (2020)
• Node.js ships subpath exports, providing built-in CommonJS <> ESM interop (2020)
• Deno 1.0, a 100% ESM competitor to Node, is released (2020)
• Node.js 10’s EOL means package maintainers can now ship ESM-first packages (2021)
• Another ESM build tool appears on the scene (2021)

It’s been rewarding to watch the web progress as we envisioned 2 years ago. And we’re proud Snowpack has played a big role in that direction.

What’s next for Snowpack

Snowpack’s original goal was to simplify the overcomplicated toolchain developers had to wrestle with to ship the most basic of websites. And Snowpack achieved that! So well, in fact, it started doing more than simply building websites; it’s now starting to be used to make new generation of build tools. Nate Moore’s Microsite and our own Astro are key examples of how Snowpack can convert almost anything you throw at it into plain ol’ HTML/CSS/JS (and do it blazing-fast, to boot).

Our vision for the future of Snowpack centers around improving this foundation for new generation of web tooling. Developers should be able to use all of npm and modern JS without wrestling with all the complexity themselves. Here are some upcoming highlights:

• ⚡️ Improved SSR API. The future of the web is SSR. Today, Snowpack’s SSR engine requires hard files and disk access. Snowpack was also originally designed for shipping code to browsers, which can limit an SSR build when Node.js is needed to execute. Snowpack v4 will introduce virtual file support which will allow Snowpack to do more in-memory for flexibility and performance, as well as full Node.js SSR support for people to unlock the full power of Node. Imagine being able to power servers with Snowpack and being able to SSR on-the-fly, all while managing less of that yourself!
• 🐇 All-in on esbuild. Snowpack was quick to adopt Go-powered esbuild, and it’s payed dividends in performance. But Snowpack has also had to build out features while the esbuild project matured, with the end result being duplication between the two. There’s more performance Snowpack could be tapping into, but it could require a bit of work behind-the-scenes. And let’s not forget about esbuild’s list of community plugins that are starting to catch up to all that Snowpack can do, but with theoretically faster performance. By betting on esbuild and letting it power more in Snowpack, Snowpack can focus on providing everything esbuild doesn’t: an HMR-powered dev server, SSR APIs, streaming imports, and everything else to come.
• 🍱 Multi-platform targeting. Snowpack’s original design assumed a browser target, which while a great starting point, it’s incomplete with HTML, CSS, and JS turning into more universal languages that power even desktop and mobile apps, and with webviews becoming a core foundation of software in general. Snowpack v4 will introduce multi-platform targeting which means you’ll be able to use Snowpack to build for more than just browsers.
• 🧩 Improved JS API. The CLI came first in Snowpack, followed by the JS API, and it shows in several areas. Snowpack v4 will take on the remaining work making the JS API feature complete, and moving it to be the core of Snowpack. In the process, we’ll be able to clean up Snowpack and make more room for even more in v5 and beyond.

The overall goal with the next major release of Snowpack is to open up more possibilities for building for the web.

Snowpack Community 2.0

We realize over the past few months Snowpack releases, development, and community management has come in waves. This is largely being limited by only a couple core maintainers. We’d like to do better not only being consistent ourselves, but help shepherd more contributors into becoming more dedicated core maintainers. So in that light, look forward to a new Governance Model for Snowpack that will improve the following:

• Clearer path from contributing to becoming a core maintainer
• Clearer responsibilities for core maintainers
• More regular maintainer discussions & meetings.

Whether you’re new to Snowpack altogether, or if you’ve been following the project for a while but have been confused how to get more involved, all of this will help!

We’re hoping that this feels like a “Day 1” for a new contributor community.

There’s never been a better time to get involved! If you’d like to learn more about contributing, head over to the Snowpack Discord’s #contributing channel!

Thanks so much for making Snowpack what it is today. We couldn’t do it without each and every one of you 🗻.

[lgarron]

Could I ask for an update on this? 🥺😃🙏

We're currently unable to use Snowpack's dev server for https://github.com/cubing/cubing.js to work in Safari or Firefox stable, because we're using new ES features like #private fields. :-/

esbuild can handle this perfectly well, and does so for the production build. However, the inability to control settings passed to esbuild for the dev server have caused various issues for us, as has the outdated vendored version of esbuild. I could file more individual bugs (and I've submitted a fix in one case) but I'm bumping up against more issues than I'd like to keep track of and I don't want to be bothersome if all those issues would effectively be blocked on this one.

Given that this issue hasn't had an update in 2 months, it seems like a low priority (which I can understand; there's a lot of parts to Snowpack) and that we should move to another bundler if we want a better dev server experience. I'd really appreciate an update before abandoning Snowpack, though!

[FredKSchott]

Hey everyone, I just posted a blog post to dev.to that includes some context on some burnout that I experienced while maintaining Snowpack and some thoughts on the current state of Snowpack. I figured it was worth sharing here: https://dev.to/fredkschott/5-more-things-i-learned-building-snowpack-to-20-000-stars-5dc9

It's hard to summarize the post without losing important context, so I won't add a tl;dr. But I will say: it felt really nice saying out loud a question that has been bugging me for a while now: what should we do about Vite? We live in a world where Vite is well maintained, has community buy-in across multiple projects/ecosystems, and is a pretty straightforward drop-in replacement for Snowpack in most projects. I've personally heard from several users and build tool authors who transitioned from Snowpack to Vite and were happy with the result. We even have an experiment going on inside of Astro that fixes some bugs by converting from Snowpack to Vite.

I have so much love for this project and the people who have used it, contributed to it, and believed in it since day one. Snowpack isn't going anywhere. But I think it is time for a convo about what path forward is best for existing Snowpack users. The best path forward might be a clean migration to a similar-but-better-maintained project like Vite.

[jacty]

Hey everyone, I just posted a blog post to dev.to that includes some context on some burnout that I experienced while maintaining Snowpack and some thoughts on the current state of Snowpack. I figured it was worth sharing here: https://dev.to/fredkschott/5-more-things-i-learned-building-snowpack-to-20-000-stars-5dc9

It's hard to summarize the post without losing important context, so I won't add a tl;dr. But I will say: it felt really nice saying out loud a question that has been bugging me for a while now: what should we do about Vite? We live in a world where Vite is well maintained, has community buy-in across multiple projects/ecosystems, and is a pretty straightforward drop-in replacement for Snowpack in most projects. I've personally heard from several users and build tool authors who transitioned from Snowpack to Vite and were happy with the result. We even have an experiment going on inside of Astro that fixes some bugs by converting from Snowpack to Vite.

I have so much love for this project and the people who have used it, contributed to it, and believed in it since day one. Snowpack isn't going anywhere. But I think it is time for a convo about what path forward is best for existing Snowpack users. The best path forward might be a clean migration to a similar-but-better-maintained project like Vite.

I think the reason we are losing users is because of delay. I have been following this rep and trying to help as much as I can in issues and found out that many issues have been leave unresolved for long even without a reply from official member. It is just like a poor customer service. And our official website even has many wrong links and UI problems. All those just make new users feel cold to make a try, I guess.

[lgarron]

Hey everyone, I just posted a blog post to dev.to that includes some context on some burnout that I experienced while maintaining Snowpack and some thoughts on the current state of Snowpack. I figured it was worth sharing here: https://dev.to/fredkschott/5-more-things-i-learned-building-snowpack-to-20-000-stars-5dc9

Just wanted to say thanks for posting this! It's really useful to context. Snowpack really helped set a standard for the ecosystem, but if you're burned out you should make sure you take the time you need for yourself! 👍

In the JS ecosystem, using any given bundler carries some risks, including something like this, and even for our pure TypeScript library we've constantly had to investigate deal-breaking bugs across bundlers. It's much more useful to know if the maintainers are facing burnout, so that we can look into alternatives instead of spending time filing careful issues that (unfortunately) create more work for people in your situation.

[httpete]

If Snowpack is really going down, it would be nice to collaborate on how projects that count on it can ween off. I am already trying to find the esbuild / esinstall combination that can let me limp off onto the most minimal set of components needed to build the current snowpack /build directory. The single page app use case is nailed by Vite. I am producing a React component library with TS that gets consumed in a larger app, and I just want ESM from the browser to load them.

[lgarron]

If Snowpack is really going down, it would be nice to collaborate on how projects that count on it can ween off. I am already trying to find the esbuild / esinstall combination that can let me limp off onto the most minimal set of components needed to build the current snowpack /build directory.

I converted our project to use raw esbuild and < 200 lines of no-dependency code that:

• Runs esbuild in watch mode to convert all the .ts entry files form a source folder.
• Serves from the esbuild output folder with a fallback to the source folder for static files.

So far, this seems to work at least as well as any other bundler we've tried. It avoids the few dozen bugs I've filed against bundlers, because it leaves the hard part to esbuild and avoids anything "clever" for the rest. (The only feature it's missing is automatic page refresh.)

I could split that off into a separate package if there's interest.

EDIT: Actually, I've gone ahead and done that: https://github.com/lgarron/barely-a-dev-server

[FredKSchott]

I converted our project to use raw esbuild and < 200 lines of no-dependency code that:

• Runs esbuild in watch mode to concert all the .ts entry files form a source folder.
• Serves from the esbuild output folder with a fallback to the source folder for static files.

So far, this seems to work at least as well as any other bundler we've tried. It avoids the few dozen bugs I've filed against bundlers, because it leaves the hard part to esbuild and avoids anything "clever" for the rest. (The only feature it's missing is automatic page refresh.)

I could split that off into a separate package if there's interest.

EDIT: Actually, I've gone ahead and done that: https://github.com/lgarron/barely-a-dev-server

Nice!

If Snowpack is really going down, it would be nice to collaborate on how projects that count on it can ween off. I am already trying to find the esbuild / esinstall combination that can let me limp off onto the most minimal set of components needed to build the current snowpack /build directory. The single page app use case is nailed by Vite. I am producing a React component library with TS that gets consumed in a larger app, and I just want ESM from the browser to load them.

Vite and Snowpack are very similar, if you don't have a snowpack.config.js file they should be almost drop-in replacements. Maybe a migration guide to help anyone who wants to move a more complex?

[httpete]

I have been working on a snowflake-pack which is the lightest, smallest, snowpack replacement possible that only relies on esbuild.

I think snowpack got out over its skis a bit and tried to do too much for too many.

The bottom line is, you can take the incredible foundation that snowpack laid, and do it yourself with esbuild, a few plugins, and a few scripts. This lets you take command over your pipeline just to what you need, and not get wrapped up in "magic" from snowpack.

Esbuild has legs. Esinstall is slam dunk and works perfectly. Eventually, everyone will ship ESM and you probably won't need esinstall.

Get to know esm, and how it loads in the browser, and you will leave your bundles of goo from webpack behind. Although you will see more requests, they are small and cached fast.

It supports the most minimal features possible to accomplish:

• Uses esinstall to produces an esm web_modules directory based on dependencies from package.json
• Uses live-server to have a hot reloading dev server
• Consumes the esinstall generated import map through the esbuild-importmap-plugin
• Uses esbuild-glob-plugin for easier entry point mapping.
• Produces a @yourcompany namespace based on the ts / ts in ./src preserving the dir struct just like snowpack

As a follow up to this, I have outlined the parts here:

https://github.com/trygve-lie/esbuild-plugin-import-map/issues/33

[melink14]

I have completed a proof of concept based on https://github.com/withastro/snowpack/issues/3491#issuecomment-949952662 and it works pretty well. The primary downside is having to enumerate the packages for esinstall but my packages change seldom enough that it probably won't be a problem. It seems like it's not enough to just scan packages.json since sub packages won't be found.

There's also minor quality of life missing like copying static assets to the out directory and nice plugins like string replace which I needed to find esbuild equivalents for or code in node myself.

I had to do some initial work to replace my snowpack plugin for @web/test-runner but because they already have a esbuild and import-map plugin I was able to do something almost equivalent to what we did for the build process.

I'll link my final migration pull request when I send it after cleaning up the code!

[FredKSchott]

Thanks @melink14 & @httpete for exploring some of this and keeping this conversation going. Is anyone interested in creating a well-maintained fork of Snowpack or creating & maintaining a public, simpler Snowpack-alternative like the ones outlined above?

If we have viable, well-maintained alternatives then we should start thinking about some next step to begin pointing new users there with a banner on the homepage.

[httpete]

Fred - at the end of the day, my solution was just esbuild. I even gave up on the unbundled part and esinstall, and having to deal with sourcemaps and the esbuild sourcemap plugin. Esbuild, with live-server and my use case is set. I was attracted to the unbundled idea but the complexity of uniform minification, reliance on too many plugins (Which proved to be troublesome like esbuild-plugin-glob) I am convinced that for the time being a tightly managed and understood esbuild configuration is a solid foundation.

[FredKSchott]

Update: I'm planning to add a message to the README and homepage, explaining that the project is no longer actively maintained and pointing users to use esbuild or Vite instead. If anyone wants to fork snowpack and create a new project from its ashes, I'd happily point users to that repo as well.