You can read the full release notes below. But first, a look ahead...
The Road to Snowpack v2.0
As it stands, v1.7 is our last planned v1.x release before v2.0.
The project has grown a ton over since our v1.0 release: 160+ PRs, 50+ contributors, and a collection of podcasts, blog posts, video tutorials and more. I'm overjoyed that this project has meant so much to so many. If you're reading this, thank you.
We've also learned a ton from you in the process: what works, what doesn't, and what's still confusing. It turns out, there's still a lot to get confused about. This will be our focus for v2.0: The fastest dev environment on the web should also be the easiest to use.
- Remove our npm coupling: Configuring Snowpack to re-run every npm install/uninstall/add/remove can be a pain. That's why Snowpack v2.0 will also be able to install and manage dependencies independently from npm/yarn. Learn more...
- No more React workarounds: By letting Snowpack fully manage & install your
web_modules/directory, we can make sure that every package installs correctly from the start. No more workarounds needed for React and others! - A better dev environment: Today, Snowpack works with your favorite static dev server. This is an important goal for the project, but it's also a lot to ask a new user to set up. Starting in v2.0, Snowpack will ship a
devcommand that gives you a fully-configured dev environment, instantly. Learn more... - Better defaults: We've kept around a lot of v1.0 behavior to prevent breaking changes, but new features launched since then make more sense as defaults. v2.0 will be a chance to enable some of our favorite features from v1.x (like
--statmode) by default.
If you're interested in getting involved and helping out, this is a great time to do so! We keep our Issue tracker extremely clean so that you can always find an issue that we're looking for help on.
v1.7.0 Release Notes
--env process.env support (author: @postspectacular)
Snowpack's process.env handling has gotten an upgrade and a new feature: you can now rewrite custom process.env properties in your dependencies via --env/"env" config support. This is essential if you find yourself working with a dependency that checks for a custom property like "process.env.MY_CUSTOM_KEY" that you'd like to provide.
A better babel plugin (author: @francislavoie)
Based on your user feedback, we've completely updated our Babel plugin to better support complex project layouts. It now supports:
- webModulesUrl - Rewrite your bare module imports to an absolute path (
/web_modules/...), a relative path (../web_modules/...), or even an absolute, remote URL (https://static.yourdomain.com/web_modules/...). - moduleResolution - Resolve relative imports using Node's resolution logic. Instead of just adding missing extensions, we'll now also resolve directory imports (
/foo->/foo/index.js).
JSX & TypeScript support for --include (author: @DangoDev, @FredKSchott)
Our previous import scanner left TypeScript users, JSX users, and others stuck in a Catch-22: scanning your compiled code for new dependencies required a successful build, but creating a successful build required that new dependencies were already installed.
You can now use --include src/**/* to scan your actual source for the correct dependencies, even if you're using non-standard language features like TypeScript or JSX.