fix: declare ES module in package.json #1061
Conversation
In bundler mode, generate the package.json with "type": "module" and use the "main" attribute instead of the "module" attribute. This change makes the built ES module palatable to node in --experimental-wasm-modules mode as well as to webpack as illustrated in webpack/webpack#14313
I noticed that this specific evasion of the "type" keyword is already used in utils::manifest::NpmPackage in the tests, so just match that.
The build-wasm script was failing if you had wasm-pack built with the patch in rustwasm/wasm-pack#1061 because the "module" attribute would not be there --- so fix that by just hardcoding the filename.
Update test case that landed after this PR was created, in rustwasm#1061, to expect main attribute in package.json instead of module attribute.
|
Sorry to push, but any chance of getting this merged and released (or else a comment on why it shouldn't be)? I'm about to start jumping through hoops in CI to postprocess wasm-pack output to make it usable in a library that gets used both directly in Node.js and in a webpack build... and it would be so nice not to have to. :) |
|
Ping - I really want this feature merged too. I've settled for writing a post-processing script which inserts |
|
I don't know if this is going to be merged that soon, but isn't it better if we use the new |
When {wasm-pack} is run with browser target, it generates a {package.json}
in which there is a {module} field, but no {main}, {type} or {exports}
field is present. This causes some of the modern tools which run in Node
be unable to use the package (Vitest is an example).
Although it may seem irrational to use the browser package in Node, but
it makes sense when we want to write tests. Many test tools such as Jest
and Vitest run in Node.
Add a {set_exports} script to be run after {wasm-pack}, updating the
generated {package.json} as follows:
- Add an {exports} field to enable new Node entry resolution feature
- Add {"type": "module"} to indicate that this is an ESM module
- Remove {module}, as it's no longer needed
{wasm-pack} may fix the issue in the future or new module entry resolution
mechanisms may be introduced in the future. Until then, this script will
enable the use of the package without getting browser environment related
issues when run in Node.
Related {wasm-pack} PR:
rustwasm/wasm-pack#1061
|
I think It doesn’t matter to me, just so long as package.json isn’t broken out of the gate. (It’s broken because it claims the module is a cjs module when it’s actually an esm module). I’m disappointed this has been in a bad state so long. What do we need to do to fix this? |
|
I just think it's more modern than the
Anyway, I agree with you. Merging this PR is far more important than using either of the fields 😅 |
|
when is this out? |
|
For myself, this library is not sufficient for package publishing. I use a wrapper typescript file and rollup to publish npm package that is usable out of box. I'm using target --web and i think that is the only way. |
|
It’d be great to see this PR merged! I’ve crafted a demo where I use |
|
|
So stoked about this!! Any idea of when the next release is? Last release looks like Jun 27. I'm writing a plugin to integrate wasm-pack with Vite & Sveltekit, & I'd love to not have to manually rewrite package.json with "type":"module" |
In bundler mode, generate
package.jsonwith"type": "module"and use the"main"attribute instead of the"module"attribute.This change makes the built ES module palatable to Node.js (when run with
--experimental-vm-modules --experimental-wasm-modules), while it remains also palatable to webpack as illustrated in webpack/webpack#14313 (where thepkgsubfolder is generated withwasm-packbuilt with this change). This resolves the headache of using a wasm-pack-built package in a library that one needs to both run directly in Node and include in a webpack build.Fixes #1039
rustfmtinstalledcargo fmton the code base before submitting