Use stricter imports to satisfy webpack 5

[daniel-ac-martin]

I run my server-side code through Webpack, in addition to my client-side code. As a part of my attempt to upgrade from Webpack v4 to v5, I have run into a problem whereby these require statements are no longer transformed by Webpack and so my application is broken. (Perhaps this is because the files are otherwise in an ESM style and Webpack v5 is being stricter than v4? Then again, this could just be a quirk in my set-up. - Has anyone else run into these problems?)

Note: I don't know if this solution is acceptable, as you may have had the require inline for a reason. (To avoid importing it when it isn't going to be overridden by the consumer?) There may also be a way to make Webpack v5 accept the code as it is. I've asked for guidance from the Webpack community here: webpack/webpack#15670

Please accept my apologies if I'm being silly.

[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/

[daniel-ac-martin]

Adding the following rule to the webpack v5 config, avoids the need for this change:

{
    [...]
    module: {
      rules: [
        {
          test: /\.js$/,
          include: /node_modules/,
          type: 'javascript/auto'
        },
        [...]
      ]
    }
}

i.e. Setting the type to javascript/auto, whereas it would have been under, the more strict, javascript/esm.

It would be nice to avoid this workaround, if possible. I'm not sure if there's anything that can be done in @apollo/client to encourage the file to be processed correctly.

I was also wondering if this 'mixed syntax' file is really the correct thing to be published. - Perhaps the 'ssr' code should have its own .tsconfig that compiles to CommonJS modules?

[hwillson]

Thanks for this @daniel-ac-martin and sorry for the delay. Yes those inline requires are there for a reason, which you can read about here: apollographql/react-apollo#2627

That being said, we're exploring a new approach for this in #9975 (more changes coming there shortly).