Use stricter ESM imports to satisfy webpack 5

[daniel-ac-martin]

Fixes an issue in which webpack 5 will complain due to requiring the file extension (.js) for ESM imports. (In this case the built NPM package has "type": "module".)

This manifests as an error message similar to the following:

ERROR in node_modules/@apollo/client/react/ssr/getDataFromTree.js 5:0-56
Module not found: Error: Can't resolve 'react-dom/server' in '/path/to/your/project/node_modules/@apollo/client/react/ssr'
Did you mean 'server.js'?
BREAKING CHANGE: The request 'react-dom/server' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

(FWIW, this is somewhat a reprisal of a previous PR, that couldn't go in due to other issues at that time: #9601 )

I think this will have been an issue for some time, but presumably not so many people will be using SSR, and even fewer will be running their server-side code through webpack.

[apollo-cla]

@daniel-ac-martin: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/

[netlify]

👷 Deploy request for apollo-client-docs pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	ca4de1d

[changeset-bot]

🦋 Changeset detected

Latest commit: ca4de1d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@apollo/client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[daniel-ac-martin]

Apologies, this breaks the tests.

I think that either the test suite would need changes to support this, or the approach is wrong and the correct method would be to coax TypeScript into outputting the file extension in the resulting .js files. (Or to remove "type": "module" from the built package.json.)

[jerelmiller]

@daniel-ac-martin What version of React are you using by chance? It looks like perhaps this might be on the React end? I found this issue that looks very similar due to export conditions not specified correctly. Looks like this should be fixed in React 18 according to that issue.

I saw something similar in react-dnd which suggested adding resolve.fallback option to your webpack config to know how to resolve this package.

I'll be honest I'm not the most knowledgable in the ESM/CJS exports/bundling world. Hopefully this points you in the right direction though!

[daniel-ac-martin]

Hi @jerelmiller.
I'm still on v16, so I think you are probably right! - The issue that you linked to does indeed sound identical, so hopefully when I'm able to upgrade to React v18 this issue should go away.
Thanks for the help. :-)

[daniel-ac-martin]

It looks like there might also be a workaround in Webpack: https://webpack.js.org/configuration/module/#resolvefullyspecified
(Taken from fullcalendar/fullcalendar#7114 (comment) )