Snowpack
Publikováno: 14.1.2020
Snowpack. Love that name. This is the new thing from the Pika people, who are on to something. It's a bundler alternative, in a sense. It runs over packages you pull from npm to make sure that they are ES module-compatible (native imports).
This is how I digest it. When you write a line of code like:
import React from "react";
That's actually invalid JavaScript. It looks like a native import, but it isn't. (It would start with … Read article
The post Snowpack appeared first on CSS-Tricks.
Snowpack. Love that name. This is the new thing from the Pika people, who are on to something. It's a bundler alternative, in a sense. It runs over packages you pull from npm to make sure that they are ES module-compatible (native imports).
This is how I digest it. When you write a line of code like:
import React from "react";
That's actually invalid JavaScript. It looks like a native import, but it isn't. (It would start with a filepath character like ./
and end in .js
to be valid.) It's just an agreement from Big Bundler like, "Oh, I know what you mean. You mean I should go look in node_modules
for this thing." Then it goes and does it.
A lot of stuff on npm isn't ready for ES modules. It's in some other module format (e.g. CommonJS) and assumes you'll be using a bundler with it. An assumption served them just fine for a while, but it's an assumption that is starting to be a bit of a thorn for front-end developers.
UNPKG has had a feature where you could add ?module
to the end of their URLs to get it to serve up an ES module-friendly version of the package, but it's been in an experimental stage for a long time because, presumably, it's a hard problem to solve. Which packages are ready for ES modules? Can they be processed to be ready on the fly?
Even the Pika CDN doesn't solve the issues of packages that aren't written to be used via ES modules. For example, since React isn't written to be used with ES modules directly, so you just can't (but you can still use it via <script>
tag).
Snowpack has apparently dealt with this. It runs its magic over the packages that you install (locally) and prepares them for ES module usage. So, after Snowpack has ran, now you can do this (which you haven't been able to do before):
import React from '/web_modules/react.js';
Which is valid code for ES modules. Plus, if you run Babel anyway, you don't even have to change that original line.
Hence their marketing/explanation:
1) Instead of bundling on every change, just run Snowpack once right after
npm install
.
2) Snowpack re-installs your dependencies as single JS files to a newweb_modules/
directory.
3) Write code, import those dependencies via an ESMimport
, and then run it all in the browser.
4) Skip the bundle step and see your changes reflected in the browser immediately after hitting save.
5) Keep using your favorite web frameworks and build tools! Babel & TypeScript supported.
It's kinda like you get native code splitting for free, and you're just crossing your fingers that ES modules will be just as fast as bundling with that benefit. I'm optimistic. I think it's early days and would be nervous on Big Production Stuff, but I also think native ES modules are probably the future.
The post Snowpack appeared first on CSS-Tricks.