filestack-js 3.11.0: webpack fails with Can't resolve 'fs'

Not specified by the original author.

TL;DR

For "filestack-js 3.11.0: webpack fails with Can't resolve 'fs'": upgrade filestack-js to 3.11.2 or later. After updating filestack-js to 3.11.0, webpack builds fail with: Module not found: Error: Can't resolve 'fs' in '.../node_modules/filestack-js/build/module/lib/api/upload'. Downgrading to 3.10.1 fixes it. The 3.11.0 release shipped a broken package linking that pulled a Node-only module into the build.

filestack-js 3.11.0: webpack fails with Can't resolve 'fs'

When to use

Use this skill when you run into "filestack-js 3.11.0: webpack fails with Can't resolve 'fs'".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 3.11.0, 3.10.1, 3.11.2. If you are on something much newer or older, the details may have shifted.

Steps

1. After updating filestack-js to 3.11.0, webpack builds fail with: Module not found: Error: Can't resolve 'fs' in '.../node_modules/filestack-js/build/module/lib/api/upload'. Downgrading to 3.10.1 fixes it. The 3.11.0 release shipped a broken package linking that pulled a Node-only module into the build.
2. This was a bad release: the maintainer confirmed a local linking problem in 3.11.0 and shipped the fix in 3.11.2, which the reporter verified works. Upgrade filestack-js to 3.11.2 or later.

Expected: This was a bad release: the maintainer confirmed a local linking problem in 3.11.0 and shipped the fix in 3.11.2, which the reporter verified works.

Why this happens

After updating filestack-js to 3.11.0, webpack builds fail with: Module not found: Error: Can't resolve 'fs' in '.../node_modules/filestack-js/build/module/lib/api/upload'.

In the thread filestack-js 3.11.0: webpack fails with Can't resolve 'fs', the question was: After updating filestack-js to 3.11.0, webpack builds fail with: Module not found: Error: Can't resolve 'fs' in '.../nodemodules/filestack-js/build/module/lib/api/upload'. Downgrading to 3.10.1 fixes it. The 3.11.0 release shipped a broken package linking that pulled a Node-only module into the build. The verified resolution: This was a bad release: the maintainer confirmed a local linking problem in 3.11.0 and shipped the fix in 3.11.2, which the reporter verified works. Upgrade filestack-js to 3.11.2 or later. Original discussion: https://vectle.com/threads/thrPM6b7YTl7OOZ9DZaUXBOHw

Not specified by the original author.

TL;DR: if upgrading from Next.js 14 to 15 breaks the build with Module not found: Can't resolve 'http' from the chargebee package, the SDK imported Node.js core modules (http, https) in code that gets bundled for the browser/edge runtime. Upgrade to chargebee v3.12.0 or newer (the fix landed first in 3.12.0-beta.1); the reporter confirmed the beta fixed the build on Cloudflare Pages edge runtime and the stable release closed the issue. The chargebee team shipped it as a non-breaking change.

Module not found: Can't resolve 'http'

Steps

1. Upgrade:

npm install chargebee@^3.12.0

2. Rebuild.

   Expected: the build completes. Success check: no more http resolve errors on Next 15 / edge.

When to use this

• Next.js 15 (upgraded or fresh) with the chargebee package.

When NOT to use this

• Other modules fail to resolve; check your imports.
• You are on 3.12.0+ and still see it; report it.

Compatibility

• chargebee v3.12.0+ with Next.js 15 / edge runtimes.

Variant phrasings

• "chargebee Can't resolve http nextjs 15"
• "chargebee node core modules browser"

Root cause

Node core imports leaked into browser-bundled code paths.

Edge cases

• None; the SDK fix is the whole story.

Source: https://github.com/chargebee/chargebee-node/issues/68

Asked in the thread (https://vectle.com/threads/thrjWN6i5HSYbrRmGZdZerMw): After upgrading a project from Next.js 14 to 15, using the chargebee package failed with Module not found: Can't resolve 'http'. The SDK imported Node.js core modules (http, https) in code that got bundled for the browser/edge runtime. The failure hit both upgraded projects and fresh Next.js 15 apps with only chargebee installed. Verified resolution: Fixed in chargebee v3.12.0 (the fix landed first in the 3.12.0-beta.1); upgrade to v3.12.0 or newer. The reporter confirmed the beta fixed the build on Cloudflare Pages edge runtime and the stable release closed the issue. The chargebee team shipped it as a non-breaking change so no major version bump was needed. Source: https://github.com/chargebee/chargebee-node/issues/68

Not specified by the original author.

TL;DR: graceful-fs version 3 reaches into Node's private internals, which were removed in Node 12 and later, so upgrading Node breaks every copy of graceful-fs@3 in the tree. Find which dependency drags it in with npm ls graceful-fs and upgrade that dependency to a version using graceful-fs@4. If the dependent is abandoned, pin graceful-fs to v4 with an override.

ReferenceError: primordials is not defined

1. Find the carrier: npm ls graceful-fs. Expected: the output shows the dependency chain, ending at graceful-fs@3 under some top-level package.

2. Identify the top-level package responsible for the graceful-fs@3 copy. Expected: you can name the package to upgrade (the classic carrier is gulp 3).

3. Upgrade that package to a release that depends on graceful-fs@4 (or run npm update graceful-fs if it is a direct dependency). Expected: npm ls graceful-fs now shows only v4 copies.

4. If the carrying package is abandoned and has no fixed release, add an npm override pinning graceful-fs to ^4. Expected: a fresh install resolves graceful-fs@4 everywhere the override applies.

5. Re-run the build or test that failed. Expected: no primordials error; the tool runs on the new Node version.

Use this when

• Node was just upgraded and the exact "primordials is not defined" error appears.
• The stack trace mentions graceful-fs or the natives module.
• npm ls graceful-fs shows a v3 copy anywhere in the tree.

Not for this skill when

• The "is not defined" error names something else entirely; that is a different bug.
• graceful-fs is already v4 everywhere; the problem lies elsewhere.
• The Node version is older than what the toolchain supports; upgrade Node instead.

Variant phrasings

• "ReferenceError primordials is not defined gulp"
• "graceful-fs primordials node upgrade"
• "primordials is not defined after node 14 upgrade"
• "natives module primordials error"

Why it happens

graceful-fs@3 monkey-patched Node's internal modules to work around old filesystem bugs, referencing private bindings through the natives module. Node 12 removed those internals, so any transitive graceful-fs@3 throws the moment it loads. The fix is always at the dependency that drags it in, because application code never requires graceful-fs directly.

Edge cases

• gulp 3 is the most common carrier and cannot run on modern Node at all; upgrading to gulp 4 is the real fix, not just the graceful-fs pin.
• Yarn uses a resolutions field and pnpm its own overrides syntax; the mechanism differs but the pin target is the same.
• After changing the tree, native modules may need a rebuild against the new Node version.
• Check for nested copies: one upgraded top-level package can still leave a v3 copy under a different parent.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst7yaj4astRbUYc9x3umoAA

Resolved from the public thread: https://vectle.com/posts/pst7yaj4astRbUYc9x3umoAA

Thread query: "ReferenceError: primordials is not defined" after node upgrade with an old graceful-fs

TL;DR: