Consider offering prebuilt binaries with no postinstall step

[shamilovtim]

Description

npm postinstall scripts are a significant security risk in the JavaScript ecosystem and are frequently used as an attack vector in supply-chain incidents. Given the current threat landscape, many teams are moving toward blocking or heavily restricting these scripts by default.

Skia is the only remaining package in our monorepo that needs postinstall step. Is it possible to have an alternative approach to shipping prebuilt binaries?

[wcandillon]

The prebuilt binaries come from npm packages with provenance=true on them, so that part is good. Now we still rely on the postinstall step to copy these prebuilt binaries into the main package lib/. When we do not have the postinstall, we receive other complaints, like making cocoapods believe that it needs to reinstall the RN Skia dependency. That being said, it sounds like this topic should be revisited.

…

On Wed, May 13, 2026 at 5:23 PM Tim Shamilov ***@***.***> wrote: Description npm postinstall scripts are a significant security risk in the JavaScript ecosystem and are frequently used as an attack vector in supply-chain incidents. Given the current threat landscape, many teams are moving toward blocking or heavily restricting these scripts by default. Skia is the only remaining package in our monorepo that needs postinstall step. Is it possible to have an alternative approach to shipping prebuilt binaries? — Reply to this email directly, view it on GitHub or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[kitten]

@wcandillon: I'd like to add on something from Expo's perspective (which probably applies to all consumers, but mostly applies to cache semantics in package managers like pnpm). When the postinstall script runs, I believe, right now, it assumes that the package isn't set up yet. However, in some package managers (or re-run cases) the postinstall may already have applied. That means it's currently able to run redundantly, even if it doesn't have to.

As far as I'm aware, this is relevant for cases where a package manager may cache postinstall outcomes to a global store, and then reapply those changes. Currently, the postinstall script erases its outputs before running, which means, it sometimes runs redundantly.

That probably is a complementary easier step than what the issue here suggests, in that, assuming a package manager that actively caches and avoids work after postinstall scripts, the script is currently not able to detect whether any copying/install steps are necessary