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