`@mdx-js/loader` v1 does not work with yarn pnp or pnpm

[anomiex]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions

1.6.22

Link to runnable example

No response

Steps to reproduce

1. Use this project.
2. Run one of the following commands
   • pnpm install && pnpm build
   • yarn set version stable && yarn install && yarn build
   • yarn install --pnp && yarn build

---

The problem seems to be that

mdx/packages/loader/index.js

Lines 4 to 7 in c91b00c

	const DEFAULT_RENDERER = `
	import React from 'react'
	import { mdx } from '@mdx-js/react'
	`

assumes that @mdx-js/react will have been hoisted into the project's node_modules directory so webpack can find it when processing the transformed file later. Changing that to

const DEFAULT_RENDERER = ` 
import React from ${ JSON.stringify( require.resolve( 'react' ) ) }
import { mdx } from ${ JSON.stringify( require.resolve( '@mdx-js/react' ) ) }
`

makes it work (at least in pnpm).

I note this problem doesn't seem to occur with version 2.0.0 or later. However, I'm not using @mdx-js/loader directly, I'm using it via @storybook/addon-docs which still depends on @mdx-js/loader ^1.6.22, so updating to v2 is not currently an option.

Expected behavior

Project should build without error.

Actual behavior

Build fails with this error

ERROR in ./test.mdx 4:0-36
Module not found: Error: Can't resolve '@mdx-js/react' in '/tmp/test'
resolve '@mdx-js/react' in '/tmp/test'
  Parsed request is a module
  using description file: /tmp/test/package.json (relative path: .)
    Field 'browser' doesn't contain a valid alias configuration
    resolve as module
      looking for modules in /tmp/test/node_modules
        single file module
          using description file: /tmp/test/package.json (relative path: ./node_modules/@mdx-js/react)
            no extension
              Field 'browser' doesn't contain a valid alias configuration
              /tmp/test/node_modules/@mdx-js/react doesn't exist
            .js
              Field 'browser' doesn't contain a valid alias configuration
              /tmp/test/node_modules/@mdx-js/react.js doesn't exist
            .json
              Field 'browser' doesn't contain a valid alias configuration
              /tmp/test/node_modules/@mdx-js/react.json doesn't exist
            .wasm
              Field 'browser' doesn't contain a valid alias configuration
              /tmp/test/node_modules/@mdx-js/react.wasm doesn't exist
        /tmp/test/node_modules/@mdx-js/react doesn't exist
      /tmp/node_modules doesn't exist or is not a directory
      /node_modules doesn't exist or is not a directory

Runtime

Node v16

Package manager

yarn v3, yarn v1, pnpm

OS

Linux

Build and bundle tools

webpack

[ChristianMurphy]

Have you tried using mdx 2?

[anomiex]

See this bit in the original report.

I note this problem doesn't seem to occur with version 2.0.0 or later. However, I'm not using @mdx-js/loader directly, I'm using it via @storybook/addon-docs which still depends on @mdx-js/loader ^1.6.22, so updating to v2 is not currently an option.

[ChristianMurphy]

A similar if not the same issue is being tracked at storybookjs/builder-vite#55
And will be resolved by storybookjs/storybook#14238

MDX 2 was created to untangle the dependencies (among many other benefits).
Backporting the majors changes in version 2 back to version 1, both wouldn't be very practical (if it's possible at all), and would likely break semantic versioning.

If this support is needed, please help the projects using version 1 upgrade to version 2.

[anomiex]

A similar if not the same issue is being tracked at storybookjs/builder-vite#55

Does not appear to be at all the same. I'm using webpack, not vite.

And will be resolved by storybookjs/storybook#14238

They've only been working on that for over a year, let's go with that rather than the simple 1- or 2-line fix in this package. 🙄

[ChristianMurphy]

There was some discussion of this while version 1 was the active release line, the proposed fix is much more complex than a one line change #1300

[anomiex]

Hmm. I did miss the missing react peer dep in the fix I proposed here, and maybe fixing backslashes for Windows compatibility. It's not clear to me why the PR there resolves "react/package,json" then removes the filename though, instead of just resolving the package directly. And I only concerned myself with this loader and not the two others it seems you have.

Too bad it wasn't fixed back then. Not even by doing what someone suggested as an alternative and making the runtime a peer dep of the loader.