assuming folks approve this i'll write docs for it, and then should be ready to merge

The implementation here all looks good to me, although I might bikeshed a bit on the name. Perhaps something like --no-package-json or --no-npm-manifest or something like that? I feel like this is largely centered around the "don't do the extra steps necessary to create a package.json" part of things.

Also as a future-compatible note, this will probably want to generate a hard error if a Rust crate depends on an NPM package (e.g. when the npm dependencies implementation lands here if that is combined with --no-pack we'd want to give a first-class "this project isn't compatible with that" error)

@alexcrichton yeah i thought about a manifest related type name, i'm happy to do that

if i am understanding the ask, i actually imagine the end user would want a package.json... it'd be necessary. we could still skip the cargo.toml serialization and the readme and license steps.. this convo might be best on the npm feature tracking issue tho

tho.. if we would eventually with npm feature support make a packagejson for this no pack flag... that makes the name more confusing.

i am waiting to sync up with @Pauan but i think we should probably just close this. when considered with the npm feature, this feature does not really make sense.

• copying readme + licenses: doesn't block and doesn't happen if they aren't there. --quiet can silence the warnings
• serializing the cargo.toml: should not be expensive, if we are already making a partial package.json because the package depends on an npm package it feels weird to make a feature that just copies the wasm-bindgen one over and not just do the whole thing. if it is expensive, the feature request is perf related.. not a feature request.

+1 for --no-package-json

Any progress?
I wouldn't even consider wasm-pack without this option.
In fact, it should be the default, the current wasm-pack build command makes it seem like the developers have bad taste.