The earlier build failed while parsing a WalletConnect dependency that contained optional chaining. The file had passed through babel-loader, but the resulting syntax still exceeded what the next parser accepted.
./node_modules/@walletconnect/ethereum-provider/dist/index.es.js 59:10
Module parse failed: Unexpected token (59:10)
File was processed with these loaders:
* ./node_modules/babel-loader/lib/index.js
You may need an additional loader to handle the result of these loaders.
| rpcMap: M
| },
> l = n?.filter(g => !u.includes(g)),
| d = i?.filter(g => !p.includes(g));
| if (!s && !c && !e && !(l != null && l.length) && !(d != null && d.length)) return {This is a syntax/transformation boundary. A JavaScript dependency can contain modern syntax; the problem does not require the package to be TypeScript.
The recorded versions
"@walletconnect/ethereum-provider": "2.9.0",
"@walletconnect/modal": "2.6.0",
"babel-loader": "8.3.0",
"esbuild-loader": "3.0.1",The old fix added esbuild-loader 3.0.1 and a rule scoped to WalletConnect files:
module: {
rules: [
....
// Add es loader for walletconnect v2
{
test: /node_modules[\\/]@walletconnect/,
loader: require.resolve('esbuild-loader'),
},
...
]
}The ellipses mark this as a configuration fragment, not a complete file. The actual transform target, matching rules, loader order, and Webpack parser version determine whether the output becomes compatible. A successful package install alone does not establish that.
This records the older WalletConnect 2.9.0/modal 2.6.0 and Babel-loader 8.3.0 combination. It is not a reason to apply that rule or those package versions to every current build. No dependency or application build was executed from this example.