benjamn/wryware

Version 0.5.4 of @wry/equality is causing my react-native build to fail

awatt-cox opened this issue · 4 comments

awatt-cox commented

I have a react-native project that uses @apollo/client version 3.6.9. Apollo client has a subdependency:
"@wry/equality": "^0.5.0",
Yesterday, we started having build failures with the error shown below. I looked into the issue and found that @wry/equality version 0.5.4 causes the failure. If I roll my package-lock file back to use @wry/equality 0.5.3, the issues disappear. I tried updating @apollo/client to the latest version and the problem was the same (@wry/equality 0.5.3 works, 0.5.4 fails). Please take a look at your latest build.
Thanks!

error: Error: While trying to resolve module @wry/equality from file /Users/Awatt/Desktop/_PROJECTS/manheim_mobile_new/manheim_mobile_native/node_modules/@apollo/client/core/core.cjs.native.js, the package /Users/Awatt/Desktop/_PROJECTS/manheim_mobile_new/manheim_mobile_native/node_modules/@wry/equality/package.json was successfully found. However, this package itself specifies a main module field that could not be resolved (/Users/Awatt/Desktop/_PROJECTS/manheim_mobile_new/manheim_mobile_native/node_modules/@wry/equality/lib/bundle.cjs. Indeed, none of these files exist:

  • /Users/Awatt/Desktop/_PROJECTS/manheim_mobile_new/manheim_mobile_native/node_modules/@wry/equality/lib/bundle.cjs(.native|.ios.js|.native.js|.js|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)
  • /Users/Awatt/Desktop/_PROJECTS/manheim_mobile_new/manheim_mobile_native/node_modules/@wry/equality/lib/bundle.cjs/index(.native|.ios.js|.native.js|.js|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)
    at DependencyGraph.resolveDependency (/Users/Awatt/Desktop/_PROJECTS/manheim_mobile_new/manheim_mobile_native/node_modules/metro/src/node-haste/DependencyGraph.js:311:17)
    at Object.resolve (/Users/Awatt/Desktop/_PROJECTS/manheim_mobile_new/manheim_mobile_native/node_modules/metro/src/lib/transformHelpers.js:129:24)
    at resolve (/Users/Awatt/Desktop/_PROJECTS/manheim_mobile_new/manheim_mobile_native/node_modules/metro/src/DeltaBundler/traverseDependencies.js:396:33)
    at /Users/Awatt/Desktop/_PROJECTS/manheim_mobile_new/manheim_mobile_native/node_modules/metro/src/DeltaBundler/traverseDependencies.js:412:26
    at Array.reduce ()
    at resolveDependencies (/Users/Awatt/Desktop/_PROJECTS/manheim_mobile_new/manheim_mobile_native/node_modules/metro/src/DeltaBundler/traverseDependencies.js:411:33)
    at processModule (/Users/Awatt/Desktop/_PROJECTS/manheim_mobile_new/manheim_mobile_native/node_modules/metro/src/DeltaBundler/traverseDependencies.js:140:31)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async addDependency (/Users/Awatt/Desktop/_PROJECTS/manheim_mobile_new/manheim_mobile_native/node_modules/metro/src/DeltaBundler/traverseDependencies.js:230:18)
    at async Promise.all (index 0)
benjamn commented

Thanks for reporting this @awatt-cox!

Does this workaround work? Specifically, the advice about putting this code in your metro.config.js file:

const { getDefaultConfig } = require("metro-config");
const { resolver: defaultResolver } = getDefaultConfig.getDefaultValues();
exports.resolver = {
  ...defaultResolver,
  sourceExts: [...defaultResolver.sourceExts, "cjs"],
};

If that workaround helps, then I believe this is a known React Native problem, since the Metro bundler is refusing to use a file with a .cjs extension even though it's exactly specified as "main": "lib/bundle.cjs" in package.json (so it's not like we're expecting Metro to guess the .cjs extension, just not to reject it).

Since facebook/metro#535 has finally been fixed/closed, it sounds like the React Native team agrees it was their problem to fix, though you'll have to wait for v0.72.0 for an automatic fix.

benjamn commented

Related Apollo Client issues/PRs:

That PR apollographql/apollo-client#9716 reminds me of another solution we eventually came up with for Apollo Client, which I will try to apply here as well.

awatt-cox commented

Thanks for the tip (and the quick response to my issue). After following some of the links you posted, I updated my metro.config.js and it fixed the issue. Here's my final config code:
const defaultSourceExts = require('metro-config/src/defaults/defaults').sourceExts;

module.exports = {
  transformer: {
    getTransformOptions: () => ({
      transform: {
        experimentalImportSupport: false,
        inlineRequires: true,
      },
    }),
  },
  resolver: {
    sourceExts: process.env.RN_SRC_EXT
      ? [...process.env.RN_SRC_EXT.split(',').concat(defaultSourceExts), 'cjs'] // <-- cjs added here
      : [...defaultSourceExts, 'cjs'], // <-- cjs added here
  },
};
  • 👍2
  • 🎉1
benjamn commented

Great, thanks for confirming my suspicions!

Since that workaround worked, I implemented a more robust solution that should make the resolver.sourceExts configuration unnecessary (#484).

I've published those changes in @wry/equality@0.5.5, so running npm i @wry/equality@latest should allow you to remove the extra configuration if you like.