📦✨ your favorite rust -> wasm workflow tool!
Check for "rustup" rather than ".rustup" when checking for wasm32 - drager, issue/613
When we introduced support for non-rustup setups we did a check if the user was using rustup or not. However, this check was too constrained and only covered the most common cases, but it did not work for Docker setups.
This PR addresses that and it now covers Docker setups as well! When doing this fix we also found two other small issues which this PR also addresses. The first is that we did not print the helpful error message when the wasm32 target was not found and the other one was that it linked to the wrong section of the documentation.
Give user's ability to customize generated filenames with --out-name
flag - ibaryshnikov, issue/596 pull/599
When running wasm-pack build
, several files are generated. These files are named based on the name of the crate, as per your Cargo.toml
file. Sometimes- that's not the name you'd like your files to have!
You can now specify a custom name for the generated files using a new flag, --out-name
. Given a project called dom
, here's a comparison of the default and custom generated filenames:
wasm-pack build
# will produce files
# dom.d.ts dom.js dom_bg.d.ts dom_bg.wasm package.json README.md
wasm-pack build --out-name index
# will produce files
# index.d.ts index.js index_bg.d.ts index_bg.wasm package.json README.md
Fix panics in build mode --no-install
- alexcrichton, pull/598
This commit fixes the wasm-pack build --mode no-install
command from unconditionally panicking as well as --mode force
. These steps were calling an unwrap()
on an internal Option<T>
which was supposed to be set during step_install_wasm_bindgen
, but that step wasn't run in these modes. The mode configuration of steps has been refactored slightly to ensure that more steps are shared between these modes to reduce duplication.
Print unexpected panics to standard error - drager, issue/562 pull/601
Unexpected panics are unfortunate but they're currently covered up and written out to an auxiliary file. This makes panics in CI difficult to debug, especially at a glance, as CI builders are likely not uploading those files.
This PR will print to standard error for unexpected panics and then let human_panic
handle panics, just like before.
Improve error message when wasm32-unknown-unknown
is missing - drager, issue/579 pull/602
For folks with non-rustup environments (which we only started supporting in 0.7.0!), we were giving a missing target error that was not helpful!
We've updated the error message to include more information, and we've added some documentation to help explain how you can remedy the error by manually installing the target on your specific rust setup- including the fact that it may not be possible to add the target to some setups.
Check out the docs here.
Document --out-dir
flag - ashleygwilliams, issue/592 pull/593
Recently, someone asked on Discord about customizing the name of the directory that contains the assets built by wasm-pack
. We've had the out-dir
flag for a while, but it wasn't documented! Now it is.
Fix broken links in docs and update for template changes - drager, ashleygwilliams, issue/609 pull/612 pull/614
Recently, some improvements were made to the wasm-pack-template
. Additionally, there were some broken links in the documentation. We've updated the docs for the new template and fixed the broken links!
Move binary-install
to its own repo - drager, issue/500 pull/600
binary-install
is a crate that holds the abstractions for how wasm-pack
downloads and caches pre-built binaries for the tools it wraps. It was originally part of the wasm-pack
code, then moved into a workspace as an independent crate. Now that we believe it's stable, we've moved it into its own repo!
Non rustup
environment support - drager, pull/552
Before now, wasm-pack
had a hard requirement that rustup
had to be in the PATH. While most Rust users userustup
there are variety reasons to have an environment that doesn't use rustup
. With this PR, we'll now support folks who are using a non-rustup
environment!
Improved CLI Output - alexcrichton, pull/547
It's hard to decide if this is a fix or a feature, but let's keep it positive! This PR moves wasm-pack
's CLI output strategy closer to the desired standard we have for 1.0. This is important as it fixes many small bugs that are distributed across a diveristy of terminals and difficult to test for locally.
This strategy was first introduced as a mini RFC in issue/298, and then was discussed in a session at the Rust All Hands (notes).
You'll notice that the spinner is gone- we eventually want to have one, but we'd like one that doesn't cause bugs! If you have feedback about terminal support or an output bug, please file an issue! We want to hear from you!
Check out the new output in the README
demo- or update your wasm-pack
and take it for a spin!
Add support for --target web
- alexcrichton, pull/567
Recently, wasm-bindgen
add a new target- web
. This new target is similar to the no-modules
target, in that it is designed to generate code that should be loaded directly in a browser, without the need of a bundler. As opposed to the no-modules
target, which produces an IIFE (Immediately Invoked Function Expression), this target produces code that is an ES6 module.
You can use this target by running:
wasm-pack build --target web
Learn more about how to use this target by checking out the docs!
Support passing arbitrary arguments to cargo test
via wasm-pack test
- chinedufn, issue/525 pull/530
wasm-pack test
is an awesome command that wraps cargo test
in a way that helps provide you some nice out of the box configuration and setup. However, you may find yourself wanting to leverage the full funcationality of cargo test
by passing arguments that haven't been re-exported by the wasm-pack test
interface.
For example, if you have a large test suite, it can be nice to simply run one test, or a subset of your tests. cargo test
supports this, however up until now, the wasm-pack test
interface did not!
wasm-pack test
now accepts passing and arbitrary set of arguments that it will forward along to its cargo test
call by allowing users to use --
after any wasm-pack test
arguments, followed by the set of arguments you'd like to pass to cargo test
.
For example:
# Anything after `--` gets passed to the `cargo test`
wasm-pack test --firefox --headless -- --package my-workspace-crate my_test_name --color=always
This will just run the my_test_name
test and will output using color!
Support homepage
field of Cargo.toml
and package.json
- rhysd, pull/531
Both Cargo.toml
and package.json
support a homepage
field that allow you to specify a website for your project. We didn't support it previously (purely an accidental omission) - but now we do!
Support license-file
field in Cargo.toml
- rhysd, pull/527
Sometimes, you want to provide a custom license, or specific license file that doesn't map to SPDX standard licenses. In Rust/Cargo, you accomplish this by omitting the license
field and including a license-file
field instead. You can read more about this in the cargo
manifest documentation.
In an npm package, this translates to "license": "SEE LICENSE IN <filename>"
in your package.json
. You can read more about this in the npm package.json
documentation.
We previously only supported using SPDX standard licenses, by only supporting the "license"
key in your Cargo.toml
- but now we'll allow you to leverage the license-file
key as well, and will translate it correctly into your package.json
!
wasm-pack-init (1).exe
should work - ashleygwilliams, issue/518 pull/550
Several users noted that when downloading a new version of wasm-pack
their browser named the executable file wasm-pack-init (1).exe
. When named this way, the file didn't show the init instructions on execution. This happened because the installation logic was requiring an exact match on filename. We've loosened that restriction so that the filename must start with wasm-pack-init
and will still execute files with these additional, extraneous characters in the filename. Thanks so much to Mblkolo and [danwilhelm] for filing the issue and the excellent discussion!
Fix chromedriver error and message on Windows for wasm-pack test
- jscheffner, issue/535 pull/537
When running wasm-pack test
on a 64-bit Windows machine, users would receive an error:geckodriver binaries are unavailable for this target
. This error message had two issues- firstly, it accidentally said "geckodriver" instead of "chromedriver", secondly, it threw an error instead of using the available 32-bit chromedriver distribution. Chromedriver does not do a specific disribution for Windows 64-bit!
We've fixed the error message and have also ensured that 64-bit Windows users won't encounter an error, and will appropriately fallback to the 32-bit Windows chromedriver.
Correct look up location for wasm-bindgen
when it's installed via cargo install
- fitzgen, pull/504
Sometimes, when a wasm-bindgen
binary is not available, or if wasm-pack
is being run on an architecture that wasm-bindgen
doesn't produce binaries for, instead of downloading a pre-built binary, wasm-pack
will install wasm-bindgen
using cargo install
. This is a great and flexible back up!
However, due to the last release's recent refactor to use a global cache, we overlooked the cargo install
case and did not look for wasm-bindgen
in the appropriate location. As a result, this led to a bug where wasm-pack
would panic.
We've fixed the lookup for the cargo install
'd wasm-bindgen
by moving the cargo-install
'd version to global cache location for wasm-pack
once it's successfully built. We also eliminated the panic in favor of propagating an error. Thanks for your bug reports and sorry about the mistake!
Only print cargo test
output the once - fitzgen, issue/511 pull/521
Due to some technical debt and churn in the part of the codebase that handles output, we were accidentally printing the output of cargo test
twice. Now we ensure that we print it only one time!
Fix clippy
warnings - [mstallmo], issue/477 pull/478
clippy
is an awesome utilty that helps lint your Rust code for common optimizations and idioms. at the beginning of wasm-pack
development, clippy
had not yet stablized, but it has since 1.0'd and it was high time we leveraged it in wasm-pack
. We still aren't completely fixed, but we're working on it, and we've already dervived a ton of value from the tool!
Run clippy
check on Travis - drager, pull/502
Now that wasm-pack
has been clippified- we want to keep it that way! Now in addition to cargo fmt
and cargo test
, we'll also run cargo clippy
on all incoming PRs!
Port tests to use assert-cmd
- fitzgen, pull/522
assert_cmd
is a great utility for testing CLI applications that is supported by the CLI WG. wasm-pack
development began before this library existed- so we were using a much less pleasant and efficient strategy to test the CLI functionality of wasm-pack
. Now we've ported over to using this great library!
Add initial tests for binary-install
crate - drager, pull/517
In the last release, we separated some of our binary install logic into a new crate, binary-install
. However, that's about all we did... move the logic! In an effort to move the crate into true open source status, drager has done some excellent work adding tests to the crate. This was trickier than it looked and involved creating a test server! Thanks for all the efforts drager, and the great review work fitzgen and lfairy!
Update tests wasm-bindgen
version - huangjj27, issue/519 issue/417 pull/526
Our tests use fixtures that reference wasm-bindgen
often, but the versions were not consistent or up to date. As a result, the test suite leverage many version of wasm-bindgen
which meant that they took a while to run as they couldn't use the cached version of wasm-bindgen
because the cached versions we slightly different! Now they are up to date and consistent so the tests can perform better!
Flag gh-pages docs as unpublished - alexcrichton pull/565
Recently, DebugSteven made a PR to merge all the documentation for the rustwasm toolchain into a single location. This is going to make discovering and using tools from the entire organization easier for new and seasoned folks alike. This also has the feature of displaying documentation that is related to the current published version of each tool- unlike before, where the only accessible documentation was for the tools at current master (which may or may not be currently published!)
If you like reading the current master's documentation- fear not, each tool will still publish the documentation generated from the master branch on their individual gh-pages
(See wasm-pack's
master docs here). To avoid confusion, we've added a flash message that let's you know which documentation you are reading- and provides a link to documentation of the published version- just in case that's what you're looking for!
Add new QuickStart guide for "Hybrid Applications with Webpack" - DebugSteven pull/536
Since wasm-pack
was first published, we've focused on a workflow where a user writes a library and then publishes it to npm, where anyone can use it like any npm package in their JavaScript or Node.js application.
Shortly after wasm-pack
appeared, some RustWASM teammates created a template for a similar workflow- building a RustWASM package alongside an application. They did this by leveraging Webpack plugins, and it's a really lovely user experience!
[This template] hasn't gotten as much attention because we've lacked a quickstart guide for folks to discover and follow- now we've got one!
Check out the guide here!
Add wee_alloc
deepdive - surma, pull/542
wee_alloc
is a useful utility that deserved more attention and explanation than our previous docs addressed. This was partially because the wasm-pack
template has an explanatory comment that helps explain its use. However, for folks who don't use the template, wee_alloc
is something important to know about- so now we have given it its own section!
Check out the deepdive here!
Update prerequisite documentation - alexcrichton, pull/569
Many folks are using wasm-pack
without publishing to npm- as a result, we've updated the documentation to clearly indicate that npm is an optional requirement, only required for specific targets and workflows. Additionally, since the 2018 Edition landed, nightly
Rust is no longer a requirement. We've removed those instructions and have consolidated the documentation so it is shorter and more efficient at getting you started!
Clarify what kind of account login
adds - killercup, pull/539
Previously, when view --help
, the command description for login
showed: 👤 Add a registry user account!
This could be confusing for folks, so now it's been updated to read: 👤 Add an npm registry user account!
, which is much clearer!
Wasm is a contraction, not an acronym - fitzgen, pull/555
Ever wonder how you're actually supposed to refer to WebAssembly in short-form? WASM? wasm? For the pedants out there, the correct usage is "Wasm" because Wasm is a contraction of the words Web and Assembly. We've updated our documentation to consistently refer to WebAssembly as Wasm in the shortform.
The more you know!
Fix links and Rust highlightning - drager, issue/513 pull/514 pull/516
We had some broken links and missing Rust syntax highlighting in a few sections of the docs. This fixes that!
Add three build profiles and infrastructure for their toml config - fitzgen, issue/153 issue/160 pull/440
When originally conceived, wasm-pack
was exclusively a packaging and publishing tool, which naively assumed that the crate author would simply run wasm-pack
when they were ready to publish a wasm package. As a result, wasm-pack
always ran cargo build
in --release
mode. Since then, wasm-pack
has grown into an integrated build tool used at all stages of development, from idea conception to publishing, and as such has developed new needs.
In previous releases, we've supported a flag called --debug
which will run cargo build
in dev
mode, which trades faster compilation speed for a lack of optimizations. We've renamed this flag to --dev
to match cargo
and added an additional flag, representing a third, intermediary, build profile, called --profiling
which is useful for investigating performance issues. You can see all three flags and their uses in the table below:
Profile | Debug Assertions | Debug Info | Optimizations | Notes |
---|---|---|---|---|
--dev |
Yes | Yes | No | Useful for development and debugging. |
--profiling |
No | Yes | Yes | Useful when profiling and investigating performance issues. |
--release |
No | No | Yes | Useful for shipping to production. |
The meaning of these flags will evolve as the platform grows, and always be tied to the behavior of these flags in cargo
. You can learn more about these in the cargo profile
documentation.
This PR also introduces a way to configure wasm-pack
in your Cargo.toml
file that we intend to use much more in the future. As a largely convention-based tool, wasm-pack
will never require that you configure it manually, however, as our community and their projects mature alongside the tool, it became clear that allowing folks the ability to drop down and configure things was something we needed to do to meet their needs.
Currently, you can only configure things related to the above-mentioned build profiles. To learn more, check out the documentation. It leverages the package.metadata.wasm-pack
key in your Cagol.toml
, and looks like this:
# Cargo.toml
[package.metadata.wasm-pack.profile.dev.wasm-bindgen]
# Should we enable wasm-bindgen's debug assertions in its generated JS glue?
debug-js-glue = true
# Should wasm-bindgen demangle the symbols in the "name" custom section?
demangle-name-section = true
# Should we emit the DWARF debug info custom sections?
dwarf-debug-info = false
As always- there are defaults for you to use, but if you love to configure (or have a project that requires it), get excited, as your options have grown now and will continue to!
DEPRECATION: Rename --debug
to --dev
to match cargo
- fitzgen, pull/439
See the discussion of the build profiles feature above. This is a strict renaming of the previous --debug
flag, which will now warn as deprecated.
Add an option to pass an arbitrary set of arguments to cargo build
- torkve, issue/455 pull/461
As an integrated build tool, wasm-pack
orchestrates many secondary command line tools to build your package in a single command. Notably, one of these tools is cargo
. cargo
has a wide array of features and flags, and we couldn't reasonably expect to implement them all as first class features of wasm-pack
. As a result, we've created the option to allow users to pass an arbitrary number of additional flags to wasm-pack
by appending them to the wasm-pack build
command, after passing --
. For example:
wasm-pack build examples/js-hello-world --mode no-install -- -Z offline
In the above example, the flag -Z offline
will be passed to cargo build
. This feature is documented here.
Pre-build before wasm-pack publish - csmoe, issue/438 pull/444
Previously, if you ran wasm-pack publish
before you had successfully run wasm-pack build
,
you'd receive an error that a package could not be found- because there would be no pkg
or
out-directory containing a package.json
.
In this situation, you would hope that wasm-pack
would build your package for you when you
ran wasm-pack publish
. This is slightly complicated by the fact that not everyone wants to
build their package to the default target or to a directory named pkg
.
To solve this, running wasm-pack publish
before a successful build will give you an interactive
prompt to build your package- allowing you to specify your out directory as well as the target you'd
like to build to. Check it out in the gif below:
Generate self-.gitignore as part of pkg folder - RReverser, pull/453
Since wasm-pack
was first published, the pkg
directory was intended to be treated as a build artifact, and as such should never be published to version control. This was never enforced by any assets generated by wasm-pack
, however.
Now, when building your package, wasm-pack
will also generate a .gitignore
file so that the pkg
, or out-directory, will be ignored.
If you use another version control tool, you'll need to still create or edit your own ignore file- pull requests to support other version control tools are welcome!
If you require editing of the generated package.json
or add additonal assets to your package before publishing, you'll want to remove the .gitignore
file and commit to version control. We intend to have a solution that makes this workflow significantly easier in upcoming releases!
Support cargo workspaces - fitzgen, issue/252 issue/305 pull/430
Workspaces are a well-liked and used feature of cargo that allow you to build multiple crates in a single cargo project. Because of how wasm-pack
handled paths for target
and out-directories, we did not support cargo workspaces out of the box. Now they should work well and the feature is well guarded by tests!
Use a global cache for all downloaded binaries - alexcrichton, pull/426
wasm-pack
is an integrated build tool that orchestrates several other command line tools to build your wasm project for you. How wasm-pack
does this has evolved significantly since it's early versions. In the last version, a bin
directory was created to house the tool binaries that wasm-pack
needed to build our project, but this had several limitations. Firstly, it created a bin
directory in your project's root, which could be confusing. Secondly, it meant that sharing these tools across multiple projects was not possible. We did this because it gaves us the fine-grained control over the version of these tools that you used.
Now, wasm-pack
will not generate a bin
directory, but rather will use a global cache. We retain the fine-grained control over the versions of these tools that are used, but allow multiple projects that use the same tools at the same versions to share the already installed asset. Your global cache will generally be in your user's home directory- we use the dirs
crate to determine where to place this global cache. This is not currently customizable but is something we intend to look into doing!
This feature ensures that wasm-pack
users are downloading a minimal number of binaries from the network, which, for wasm-pack
users with multiple projects, should speed up build times.
Fix pack
, login
, and publish
for Windows users - danwilhelm, issue/277 pull/489
Rust's behavior for spawning processes on some Windows targets introduced an interesting case where Rust would fail unless the command was explicitly spawned with a prepended cmd /c
. This failure of wasm-pack
was well noticed by our community - and thanks to the efforts of danwilhelm
is now fixed! You can read more on the background of this issue in rust-lang/rust issue/44542.
Validate --target
argument - csmoe, issue/483 pull/484
For a few releases now, wasm-pack
has supported allowing users to specifying the target module system they'd like their package built for- browser
, nodejs
, and no-modules
. We did not however, validate this input, and so if a user made even a slight mistake, e.g. node
, wasm-pack
would not catch the error and would build your project using the default, browser
. This is of course, surprising, and unpleasant behavior and so now we'll error out with a message containing the supported target names.
Fix login - danwilhelm, issue/486 pull/487
Eliminate unecessary escaping in build success terminal output - huangjj27, issue/390 pull/396
Previously, on some systems, a successful wasm-pack build
would print a unfortunate looking string:
| :-) Your wasm pkg is ready to publish at "\\\\?\\C:\\Users\\Ferris\\tmp\\wasm-bug\\pkg".
We've updated this to make sure the path to your project is well-formed, and most importantly, human-readable.
Copy license file(s) to out directory - mstallmo, issue/407 pull/411
Since wasm-pack
was first published, we've copied over your Cargo.toml
license definition over to your package.json
. However, we overlooked copying the actual LICENSE
files over! Now we do!
Don't require cdylib crate-type for testing - alexcrichton, pull/442
wasm-pack
was unecssarily checking Cargo.toml
for the cdylib
crate type during calls to wasm-pack test
. The cdylib
output isn't necessary for the wasm-pack test
stage because wasm-bindgen
isn't being run over a wasm file during testing. This check is now removed!
Fix wasm-bindgen if lib is renamed via lib.name
- alexcrichton, issue/339 pull/435
In some circumstances, a library author may wish to specify a name
in the [package]
portion of their Cargo.toml
, as well as a different name
in the [lib]
portion, e.g.:
[package]
name = "hello-wasm"
[lib]
name = "wasm-lib"
This would cause the wasm-bindgen
build stage of wasm-pack
to error out because wasm-pack
would attempt to run wasm-bindgen-cli
on a path using the [package]
name, which wouldn't exist (because it would be using the [lib]
name). Now it works- thanks to more usage of cargo_metadata
in wasm-pack
internals!
Print standard error only once for failing commands - fitzgen, issue/422 pull/424
Previously, wasm-pack
may have printed stderr
twice in some circumstances. This was both confusing and not a pleasant experience, so now we've ensued that wasm-pack
prints stderr
exactly once! (It's hard enough to have errors, you don't want wasm-pack
rubbing it in, right?)
Add no-modules to --target flag's help text - fitzgen, issue/416 pull/417
This is an interesting one! fitzgen
very reasonably filed an issue asking to add wasm-bindgen
's --target no-modules
feature to wasm-pack
. This was confusing as this feature was indeed already implemented, and documented- BUT, notably missing from the wasm-pack --help
text. We've fixed that now- and it was an omission so glaring we definitely considered it a bug!
Replace slog
with log
- alexcrichton, issue/425 pull/434
For internal maintenance reasons, as well as several end-user ones, we've migrated away from the slog
family of crates, and are now using the log
crate plus env_logger
. Now, wasm-pack
won't create a wasm-pack.log
. Additionally, enabling logging will now be done through RUST_LOG=wasm_pack
instead of -v
flags.
Move binary installation to its own crate - drager, issue/384 pull/415
In wasm-pack 0.5.0
, we move away from cargo install
ing many of the tools that wasm-pack
orchestrates. Because we used cargo install
, this required an end user to sit through the compilation of each tool, which was a prohibitively long time. We moved, instead, to building, and then installing, binaries of the tools. This sped up build times dramatically!
This pattern has been very beneficial to wasm-pack
and is potentially something that could be beneficial to other projects! As a result, we've refactored it out into a crate and will be considering publishing it in the near future!
Replace internal Error
with failure::Error
- alexcrichton, pull/436
The story of error message handling in wasm-pack
has not been the prettiest. We originally were manually implementing errors, adding the failure
crate at one point, but not fully updating the entire codebase. With this PR, we are nearly completely handling errors with failure
, bringing the code into a much more maintainable and pleasant-to-work-on place.
Read the Cargo.toml
file only once - fitzgen, issue/25 pull/431
This is a very fun one since it fixes one of the original issues filed by ag_dubs
at the very beginning of wasm-pack
development. In a rush to implement a POC tool, ag_dubs
noted for posterity that the Cargo.toml
was being read multiple times (twice), when it did not need to be. Thanks to fitzgen
now it's read only once! A minor performance improvement in the scheme of things, but a nice one :)
Fix typo in test function name for copying the README - mstallmo, pull/412
Complete template deep dive docs - danwilhelm, issue/345 issue/346 pull/490
In a rush to publish a release, ag_dubs
left some "Coming soon!" comments on most pages of the "Template Deep Dive" docs. These docs help walk new users through the boilerplate that using the wasm-pack
template generates for you. Thanks so much to danwilhem
for picking this up and doing an excellent job!
Child Process and output management - fitzgen, issue/287 pull/392
Not exactly a "fix", but definitely a huge improvment in how child processes and their
output are handled by wasm-pack
. Ever sat at a long prompt from wasm-pack
and
wondered what was happening? No longer! Did wasm-pack
eat your test output- no more!
Less scary missing field messages - mstallmo, issue/393 pull/394
After watching a livestream of someone using wasm-pack
, fitzgen noted that folks
seemed pretty alarmed by the loud warning about missing optional manifest fields.
As a result, we are now downgrading those messages from WARN to INFO, and consolidating
them on a single line.
Add exit_status
to CLI errors - konstin, issue/291 pull/387
We'd been hiding these- but we shouldn't have been!
Remove lingering forced nightly usage - alexcrichton, pull/383
In 0.5.0 we removed all forced nightly usage as we depend on ~1.30
which is now
available on both nightly and beta channels! We had a bit of a race condition with
that PR and the wasm-pack test
PR, and missed a few as a result! This removes all
lingering forced nightly, which only affected the wasm-pack test
command.
Fix wasm-bindgen-test
dependency error message - fitzgen, issue/377 pull/378
The error message about missing the wasm-bindgen-test
dependency errantly stated
that the user was missing a wasm-bindgen
dependency! We've fixed it to correctly
state the missing dependency now.
We have a website now. It has the installer and links to documentation. In the future, we hope to have calls to action for folks first coming to the site who are looking to do specific things- these will help them find the docs and tutorials they need to.
This PR also has a complete rework of our documentation.
Check it out here!
BREAKING: use correct package.json
keys for generated JavaScript - ashleygwilliams, issue/309 pull/312
This is marked as potentially breaking because it changes the package.json
keys that
are generated by the project.
Previously, we generated a JavaScript file and placed it in the main
key, regardless
of what you were targeting, ES6 and Node.js alike.
We have received a lot of requests for wasm-pack
to generate "isomorphic" packages,
that contain assets that could work on both Node.js and ES6, and this led to us
looking more closely at how we are using package.json
.
With this release, we will do the following:
--target broswer
: By default, we generate JS that is an ES6 module. We used to put
this in the main
field. Now we put it in the module
field. We also add
sideEffects: false
so that bundlers that want to tree shake can.
--target nodejs
: This target doesn't change. We put generated JS that is a
CommonJS module in the main
key.
--target no-modules
: This is a new target. For this target we generate bare JavaScript.
This code is put in a browser
field.
You can see the structs that represent each target's expected package.json
here.
Thanks so much to bterlson for his help in sorting this out for us!
wasm-pack init
is now wasm-pack build
- csmoe, issue/188 pull/216
When this project was first conceived, we imagined it would be simply a way to package
up generate wasm and js and publish it to npm. Here we are at version 0.5.0
and we
have become much more- an integrated build tool!
As a result, the original command init
does a lot more than that these days. We've
renamed the command to better reflect the work it's actually doing. init
will still
work, but is deprecated now, and we will eventually remove it.
add new command: wasm-pack test
- fitzgen, pull/271
This is an experimental new command that will run your tests in Node.js or a headless
browser using wasm-pack test
. Check out this tutorial
to learn more!
add 2FA support to wasm-pack publish
- mstallmo, issue/257 pull/282
We've been wrapping the npm login
and npm publish
commands as wasm-pack login
and wasm-pack publish
for a while now- but we didn't fully support two factor
authentication. Now we do! (Be safe out there! 2FA is good for everyone!)
New target, bare JavaScript: --target no-modules
- ashleygwilliams, issue/317 pull/327
wasm-bindgen
offers a no-modules
flag that until now, we didn't support. This flag
produces bare, no modules JavaScript. So if that's your thing, this target is for you!
--access
flag for wasm-pack
publish - ashleygwilliams, issue/297 pull/299
Many of our tutorials use scopes to help prevent folks from attempting to publish packages that will lead to npm Registry errors because the package name already exists.
However, by default, scoped packages are assumed by the npm registry to be private, and
the ability to publish private packages to the npm registry is a paid feature. Worry not!
Now you can pass --access public
to wasm-pack publish
and publish scoped packages
publicly.
rustc version check - ashleygwilliams, issue/351 pull/353
Now that we have a new fangled installer, there's a chance that folks might install wasm-pack
and not have Rust installed. Additionally, now that the features we required from the nightly
channel of Rust have moved to beta
- we don't need to enforce nightly
.
As of this release, we will check that your Rust version is above 1.30.0
. You can be on
either the nightly
or beta
channel and all of wasm-pack
s calls to cargo
will
respect that.
Really hate this? You can pass --mode force
to wasm-pack
to skip this check. I hope you know
what you're doing!
coordinating wasm-bindgen versions and installing from binaries for improved speed - datapup, issue/146 pull/244 pull/324
This is the true gem of this release. Have you been frustrated by how long wasm-pack
takes to
run? Overusing --mode no-install
? This is the release you're looking for.
Many releases back we realized that folks were struggling to keep the wasm-bindgen
library
that their project used in sync with the wasm-bindgen
CLI application which wasm-pack
runs for you. This became such an issue that we opted to force install wasm-bindgen
to ensure
that every wasm-pack
user had the latest version.
Like many technical solutions, this solved our original problem, but caused a new one. Now, we
we are forcing a cargo install
of wasm-bindgen
on every run, and that means downloading
and compiling wasm-bindgen
everytime you want to run wasm-pack
. That's unacceptable!
We're happy to announce that we have a pretty great solution, and several more planned for
future releases. As of this release, we will read your Cargo.lock
to find the version of
wasm-bindgen
you are using in your local project. We will attempt to fetch a binary version
of wasm-bindgen
that matches your local version. We place that binary local to your project,
and use it when you run wasm-pack build
. The next time you run wasm-pack build
we'll use
that binary, instead of fetching a new one. We still fall back to cargo install
for
less common architectures but this is a huge speed improvement. Check out these benchmarks!
wasm-pack
v0.4.2$ time wasm-pack init # fresh build
real 1m58.802s
user 14m49.679s
sys 0m24.957s
$ time wasm-pack init # re-build
real 0m56.953s
user 11m12.075s
sys 0m18.835s
$ time wasm-pack init -m no-install # re-build with no-install
real 0m0.091s
user 0m0.052s
sys 0m0.042s
wasm-pack
v0.5.0$ time wasm-pack build # fresh build
real 1m3.350s
user 3m46.912s
sys 0m6.057s
$ time wasm-pack build # re-build
real 0m0.230s
user 0m0.185s
sys 0m0.047s
$ time wasm-pack build -m no-install # re-build with no-install
real 0m0.104s
user 0m0.066s
sys 0m0.041s
enforce cargo build
with --lib
- ashleygwilliams, issue/303 pull/330
Right now, wasm-pack
only works on Rust library projects. But sometimes, if you're
new to Rust, you might end up having a main.rs
in your project, just by mistake.
Some folks ran into this and realized that it can cause issues!
As a result, we are enforcing that cargo build
only build the library at this time.
Want to use wasm-pack
on a binary application? We're interested in hearing from you!
Checkout issue/326 and please comment! We want to support binary applicaitons in
the future and are always happy and curious to hear about how folks use wasm-pack
!
Appveyor Windows Pre-Built binaries - alexcrichton, issue/147 pull/301
We finally got Appveyor to publish pre-built binaries to GitHub releases. Aside: I really wish there were an easier way to test and debug this stuff.
new experimental installer - alexcrichton, pull/307
Whew, this one is exciting. Up until now, wasm-pack
has been distributed using
cargo install
. This is not ideal for several reasons. Updating is confusing,
and every time it's installed the user has to wait for it to compile- right at the
moment they just want to hurry up and use it already.
Say hello to the new wasm-pack
installer- we have an executable for Windows
and a curl
script for *nix users. Not pleased with that? File an issue for your
preferred distribution method and we'll do our best to get it working!
This is experimental- so please try it out and file issues as you run into things!
You'll always be able to use cargo install
as a backup.
Checkout the new installer here!
improve readability of warnings about missing optional fields - twilco, pull/296
A little punctuation goes a long way. Error message improvement PRs are the best.
update links in README - alexcrichton, pull/300
We had a real dicey documentation situation for a while. Sorry about that, and thank you SO MUCH to all the folks who filed PRs to fix it.
fix broken links in book by using relative paths - mstallmo, issue/325 pull/328
recognize [dependencies.wasm-bindgen]
during dep check in init
- ashleygwilliams, issue/221 pull/224
When we originally implemented the dependency check in wasm-pack init
we naively only checked for the "simple" dependency declaration, [dependencies] wasm-bindgen="0.2"
. However! This is not the only way to declare this dependency, and it's not the ideal way to do it if you want to specify features from the crate. Now that a bunch of folks want to use features = ["serde-serialize"]
we ran into a bunch of folks having issues with our naive dependency checker! Thanks so much to turboladen for filing the very detailed issue that helped us solve this quickly!
PSSSST! Curious what features = ["serde-serialize"]
with wasm-bindgen
actually does? It's awesome:
It's possible to pass data from Rust to JS not explicitly supported in the Feature Reference by serializing via Serde.
Read the Passing arbitrary data to JS docs to learn more!
improve UX of publish and pack commands - Mackiovello, pull/198
Previous to this fix, you would need to be in the parent directory of the /pkg
dir to successfully run pack
or publish
. This was pretty crummy! Thankfully, Mackiovello swooped in with a fix, that you can find documented in the pack and publish docs!
use PathBuf
instead of String
for paths - Mackiovello, pull/220
This is mostly a maintenance PR but does fix one very small bug- depending on if you add a trailing slash to a path that you pass to init
, you might have seen an extra /
! Now that we're using a proper Type to handle this, that's much better, and in general, all the operations using paths are more robust now.
update docs and tests to eliminate no longer necessary feature flags - ashleygwilliams, pull/226
The Rust 2018 edition marches on and we are seeing feature flags drop like flies :) Instead of a whole slew of feature flags, we now only need one, #![feature(use_extern_macros)]
, and that one is also not long for this world :)
fix files
key value for projects build for nodejs
target - ashleygwilliams, issue/199 pull/205
We became aware that the files
key in package.json
did not include the additional _bg.js
file that wasm-bindgen
generates for projects being built for the nodejs
target. This resulted in the file not being included in the published package and resulted in a Module Not Found
error for folks.
This was a group effort from mciantyre with pull/200 and Brooooooklyn with pull/197. Thank you so much for your diligence and patience while we sorted through it.
clean up quicli
remnants - SoryRawyer, pull/193
In v0.3.0 we removed the quicli
dependency, however there were a few remnants left behind. They are now removed!
DOCUMENT EVERYTHING!! and deny missing docs for all future development - fitzgen, pull/208
The wasm-pack
team has worked hard on tutorial documentation and keeping the codebase as self-explanatory as possible, but we have been slowly accruing a documentation debt. This amazing PR, landed just moments before this point release and was just too good not to include. Thank you so much, fitzgen!
fix README code example - steveklabnik, pull/195
The code example in our README.md
was missing a critical pub
. It's there now!
fix README markup - Hywan, pull/202
There was an errant `
- it's gone now!
This release has a ton of awesome things in it, but the best thing is that
almost all of this awesome work is brought to you by a new contributor
to wasm-pack
. Welcome ya'll! We're so glad to have you!
--mode
flag for skipping steps when calling init
- ashleygwilliams, pull/186
After teaching and working with wasm-pack
for some time, it's clear that people would
like the flexibility to run some of the steps included in the init
command and not others.
This release introduces a --mode
flag that you can pass to init
. The two modes currently
available are skip-build
and no-installs
and they are explained below. In the future,
we are looking to change the init
interface, and potentially to split it into two commands.
If you have thoughts or opinions on this, please weigh in on issue/188!
skip-build
mode - kohensu, pull/151
wasm-pack init --mode skip-build
Sometimes you want to run some of the shorter meta-data steps that
wasm-pack init
does for you without all the longer build steps. Now
you can! Additionally, this PR was a fantastic refactor that allows even
more custom build configurations will be simple to implement!
no-installs
mode - ashleygwilliams, pull/186
wasm-pack init --mode no-installs
Sometimes you want to run wasm-pack
and not have it modify your global
env by installing stuff! Or maybe you are just in a hurry and trust your
env is set up correctly- now the --mode no-install
option allows you to
do this.
wasm-pack init --debug
Find yourself needing to compile your Rust in development
mode? You can now
pass the --debug
flag to do so! Thanks so much to clanehin for filing
issue/126 for this feature... and then implementing it!
ensure you have cdylib
crate type - kendromelon, pull/150
One of the biggest mistakes we've seen beginners make is forgetting to declare
the cdylib
crate type in their Cargo.toml
before running wasm-pack init
.
This PR fixes that, and comes from someone who ran into this exact issue learning
about wasm-pack
at JSConfEU! Love when it works out like this.
ensure you have declared wasm-bindgen as a dep - robertohuertasm, pull/162
Another easy mistake to make is to forget to declare wasm-bindgen
as a
dependency in your Cargo.toml
. Now wasm-pack
will check and make sure you
have it set before doing a bunch of long build steps :)
ensure you are running nightly
- FreeMasen, pull/172
wasm-pack
currently requires that you run it with nightly
Rust. Now, wasm-pack
will make sure you have nightly
installed and will ensure that cargo build
is run
with nightly
. Thanks so much to FreeMasen for filing issue/171 and fixing it!
fixed broken progress bar spinner - migerh, pull/164
Oh no! We broke the progress bar spinner in version 0.3.0. Thankfully, it's fixed now- with a thoughtful refactor that also makes the underlying code sounder overall.
WIP bot - ashleygwilliams & mgattozzi, issue/170
We've got a lot of work happening on wasm-pack
so it's good to have a bit
of protection from accidentally merging a Work In Progress. As a result, we
now have the WIP Github App set up on wasm-pack
. Great suggestion mgattozzi!
modularize command.rs
- ashleygwilliams, pull/182
Thanks to the growth of wasm-pack
, command.rs
was getting pretty long.
We've broken it out into per command modules now, to help make it easier to
read and maintain!
improve PoisonError conversion - migerh, pull/187
As part of the awesome progress bar spinner fix in pull/164, migerh introduced
a small concern with an unwrap
due to an outstanding need to convert PoisonError
into wasm-pack
's custom Error
. Though not a critical concern, migerh mitigated
this right away by replacing std::sync::RwLock
with the parking_lot
crate!
This cleaned up the code even more than the previous patch!
wasm category for crates.io discovery- TomasHubelbauer, pull/149
crates.io has categories to help folks discover crates, be we weren't
leveraging it! Now- if you explore the wasm
category on crates.io
you'll see wasm-pack
!
human panic is now 1.0.0 - spacekookie, pull/156
Congrats friends! We like what you do.
cleaned up the README - ashleygwilliams, pull/155
Our README
was struggling with a common problem- doing too much at once.
More specifically, it wasn't clear who the audience was, contributers or
end users? We've cleaned up our README and created a document specifically
to help contributors get up and running.
Babby's first point release! Are we a real project now?
fixed init
Is a Directory
error - ashleygwilliams, pull/139
Our new logging feature accidentally introduced a regression into 0.3.0. When
calling wasm-pack init
, if a directory was not passed, a user would receive
a "Is a Directory" Error. Sorry about that! Thanks to jbolila for filing
issue/136!
typescript files were not included in published package - danreeves, pull/138
Generating Typescript type files by default was a pretty rad feature in 0.3.0 but we accidentally forgot to ensure they were included in the published package. Thanks so much to danreeves for catching this issue and fixing it for us!