What
zapier-platform-core declares "form-data": "4.0.5" as an exact pin. Verified against the npm
registry for both currently published 19.x releases:
| core version |
declared form-data |
| 19.0.0 |
4.0.5 |
19.1.0 (latest) |
4.0.5 |
form-data@4.0.6 is published and is the first patched version for the advisory affecting
>= 4.0.0, < 4.0.6.
Why the exact pin matters here
Because it is an exact version rather than a range, an integration cannot resolve the patched
version by updating zapier-platform-core. We upgraded core 19.0.0 to 19.1.0 expecting that to
clear it, and the resolved dependency set did not change at all.
The only route left to an integration is a local overrides entry, which is a workaround rather
than a fix and has to be carried until core moves.
What we did locally, in case it is useful
"overrides": { "form-data": "^4.0.6" }
With that, exactly one form-data resolves at 4.0.6, npm audit --omit=dev goes from 2 high to 0,
and our full test suite is unchanged at 156 passing / 0 failing / 2 pending. So 4.0.6 appears to be
drop-in compatible for our usage, though our integration does not exercise the upload path where
core actually requires form-data (src/tools/uploader.js, backing z.stashFile).
Ask
Would you consider moving the declaration to a range that admits 4.0.6, or bumping the pin, in a
future core release? Happy to test a prerelease against our integration if that helps.
No urgency implied. Reporting it so the pin is visible rather than each integration discovering it
separately.
What
zapier-platform-coredeclares"form-data": "4.0.5"as an exact pin. Verified against the npmregistry for both currently published 19.x releases:
form-data4.0.5latest)4.0.5form-data@4.0.6is published and is the first patched version for the advisory affecting>= 4.0.0, < 4.0.6.Why the exact pin matters here
Because it is an exact version rather than a range, an integration cannot resolve the patched
version by updating
zapier-platform-core. We upgraded core 19.0.0 to 19.1.0 expecting that toclear it, and the resolved dependency set did not change at all.
The only route left to an integration is a local
overridesentry, which is a workaround ratherthan a fix and has to be carried until core moves.
What we did locally, in case it is useful
With that, exactly one
form-dataresolves at 4.0.6,npm audit --omit=devgoes from 2 high to 0,and our full test suite is unchanged at 156 passing / 0 failing / 2 pending. So 4.0.6 appears to be
drop-in compatible for our usage, though our integration does not exercise the upload path where
core actually requires
form-data(src/tools/uploader.js, backingz.stashFile).Ask
Would you consider moving the declaration to a range that admits 4.0.6, or bumping the pin, in a
future core release? Happy to test a prerelease against our integration if that helps.
No urgency implied. Reporting it so the pin is visible rather than each integration discovering it
separately.