Revert normalizeNonRelativeId changes in config/resolveModuleIds.ts

[benjamn]

This reverts commit 60e18e9 from PR #8396.

In theory, commit 60e18e9 should have made it easier to consume @apollo/client ESM modules in a browser environment, by rewriting non-relative imported module identifiers like

import { useState } from "react"

to

import { useState } from "react/index.js"

effectively bypassing react/package.json and its "main" field (which is not understood by browsers). Of course, the react package doesn't actually export ESM modules, and therefore can't be used natively in the browser anyway, so the rewriting doesn't help in this case.

Not helping would be one thing, but unfortunately this change introduces more problems for bundlers that expect to find a package.json file when importing non-relative dependencies. For example, webpack complains that react/index.js does not export functions such as useState (a fair criticism, since react/index.js is a CommonJS module).

Reviewing the commit message from 60e18e9, the only third-party package it names as benefitting from this extra resolution step is ts-invariant/process, which is a package we control and therefore can fix if necessary. My plan is to merge this PR into release-3.6 so we can do some additional testing of beta releases before backporting this change to v3.5.x (the main branch).

Here's a diff of import changes generated as a result of this PR, all of which seem reasonable to me: https://gist.github.com/benjamn/31c6ca0d61ca12bd42f08d3c6e6ef42b

[benjamn]

I can confirm these changes still allow @apollo/client@3.6.0-beta.0 to be consumed through an ESM-aware CDN:

await import("https://cdn.jsdelivr.net/npm/@apollo/client@3.6.0-beta.0/core/+esm")

[brainkim]

LGTM

[SimenB]

I'm still getting an error from webpack after upgrading to 3.5.3

ERROR in ../../node_modules/@apollo/client/utilities/globals/fix-graphql.js 1:0-46
Module not found: Error: Can't resolve 'ts-invariant/process' in '/workspace/node_modules/@apollo/client/utilities/globals'
Did you mean 'index.js'?
BREAKING CHANGE: The request 'ts-invariant/process' 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.
resolve 'ts-invariant/process' in '/workspace/node_modules/@apollo/client/utilities/globals'
  Parsed request is a module
  using description file: /workspace/node_modules/@apollo/client/utilities/globals/package.json (relative path: .)
    Field 'browser' doesn't contain a valid alias configuration
    resolve as module
      /workspace/node_modules/@apollo/client/utilities/globals/node_modules doesn't exist or is not a directory
      /workspace/node_modules/@apollo/client/utilities/node_modules doesn't exist or is not a directory
      looking for modules in /workspace/node_modules/@apollo/client/node_modules
        /workspace/node_modules/@apollo/client/node_modules/ts-invariant doesn't exist
      /workspace/node_modules/@apollo/node_modules doesn't exist or is not a directory
      /workspace/node_modules/node_modules doesn't exist or is not a directory
      looking for modules in /workspace/node_modules
        existing directory /workspace/node_modules/ts-invariant
          using description file: /workspace/node_modules/ts-invariant/package.json (relative path: .)
            using description file: /workspace/node_modules/ts-invariant/package.json (relative path: ./process)
              Field 'browser' doesn't contain a valid alias configuration
              /workspace/node_modules/ts-invariant/process is not a file
      /node_modules doesn't exist or is not a directory

[brainkim]

@SimenB Also seeing this in our internal stuff. We’re on it!