Packaging "rollup"

[Gordon Messmer]

Hello, rust sig,

I'm trying to package a NodeJS program, "rollup". Rollup uses wasm-pack to
build some internal Rust crates. Early attempts to package this fail
because cargo is trying to access the network.

I probably need to adapt the cargo rpm macros for this case, but that is
somewhat difficult because cargo is being called by wasm-pack.

I might be able to introduce a shell script called "cargo" (and put that at
the beginning of PATH) that expands the rpm macros and calls the real cargo
binary with a combination of the rpm macro arguments and the arguments
passed by wasm-pack, but I am wondering if you might have a more elegant
solution?

Thanks for any suggestions you might have.

https://github.com/rollup/rollup/blob/master/package.json#L43

https://github.com/drager/wasm-pack

Hello!
> Rollup uses wasm-pack to build some internal Rust crates

AFAIK, "wasm-pack" isn't packaged. The build should already fail at that 
stage.
> Early attempts to package this fail because cargo is trying to

access the network.

Can you provide a link to the SPEC file? If everything is setup 
correctly, "cargo" won't try to access the network.
> I probably need to adapt the cargo rpm macros for this case, but that

is somewhat difficult because cargo is being called by > wasm-pack.
> I might be able to introduce a shell script called "cargo" (and put

that at the beginning of PATH) that expands the rpm macros and calls the 
real cargo binary with a combination of the rpm macro arguments and the 
arguments passed by wasm-pack, but I am wondering if you might have a 
more elegant solution?

Not sure I get how this fixes anything but it looks hacky.

I recommend joining the Matrix channel for faster communication.

Am 04.11.25 um 10:16 PM schrieb Gordon Messmer via Rust:
> Hello, rust sig,
>
> I'm trying to package a NodeJS program, "rollup". Rollup uses 
> wasm-pack to build some internal Rust crates. Early attempts to 
> package this fail because cargo is trying to access the network.
>
> I probably need to adapt the cargo rpm macros for this case, but that 
> is somewhat difficult because cargo is being called by wasm-pack.
>
> I might be able to introduce a shell script called "cargo" (and put 
> that at the beginning of PATH) that expands the rpm macros and calls 
> the real cargo binary with a combination of the rpm macro arguments 
> and the arguments passed by wasm-pack, but I am wondering if you might 
> have a more elegant solution?
>
> Thanks for any suggestions you might have.
>
> https://github.com/rollup/rollup/blob/master/package.json#L43
>
> https://github.com/drager/wasm-pack

[Gordon Messmer]

On Tue, Nov 4, 2025 at 1:42 PM Blinxen Blinxen via Rust <
[e-mail]> wrote:
> > Rollup uses wasm-pack to build some internal Rust crates
>
> AFAIK, "wasm-pack" isn't packaged. The build should already fail at that
> stage.

I've already packaged wasm-pack, napi, and a bunch of other dependencies,
locally. They all need cleanup, and that will wait until I have something
that builds and runs.
> > Early attempts to package this fail because cargo is trying to
>
> access the network.
>
> Can you provide a link to the SPEC file? If everything is setup
> correctly, "cargo" won't try to access the network.

I can: https://gordonmessmer.fedorapeople.org/rollup/rollup.spec

But what I'm saying is that nothing is set up correctly yet. Some of the
setup is probably obvious and straightforward, but some of it is not.
Building deps for the built-in crates should be simple, but building the
crates probably won't be. The build process will run "npm run build" which
will run scripts defined in package.json, npm will run wasm-pack, and
wasm-pack will run cargo. wasm-pack can accept args to pass to cargo, but
that would require either modifying package.json or (maybe) using a "cargo"
shell script that injects the correct args.
> Not sure I get how this fixes anything but it looks hacky.

All of the obvious options are extremely hacky. :)
> I recommend joining the Matrix channel for faster communication.

Will follow up, there.