[gatsby-plugin-mdx] create-webpack-config loader paths in pnpm context

[ksjogo]

Coming from #21950

In a pnpm context with a site depending on a plugin which depends on gatsby-plugin-mdx the gatsby-plugin-mdx config wont work.
Original

   loader: path.join(
                `gatsby-plugin-mdx`,
                `loaders`,
                `mdx-components`
              ),

Has the problem that webpack running within the actual site root can't resolve the loader at that path, as the actual path would be:
node_modules/other_plugin/node_modules/gatsby-plugin-mdx/loaders/mdx-components.
Changing to the following seems to fix these loaders.

   loader: path.join(
                __dirname,
                "..",
                //`gatsby-plugin-mdx`,
                `loaders`,
                `mdx-components`
              ),

Though building the site will still require adding these to its package.json

@mdx-js/mdx": "^1.5.8",
"@mdx-js/react": "^1.5.8",

as they are not added to the resolve config.

[Js-Brecht]

IMO, those loaders should be resolved to absolute paths. I'd probably do it like this, but it amounts to the same thing:

loader: require.resolve(
  `gatsby-plugin-mdx/loaders/mdx-components`
),

Though building the site will still require adding these to its package.json

@mdx-js/mdx": "^1.5.8",
"@mdx-js/react": "^1.5.8",

as they are not added to the resolve config.

Those are peer dependencies for gatsby-plugin-mdx, so it doesn't really make sense for it to add them to the webpack config. It kind of pushes the responsibility of dependency management off onto the consumer.

Your plugin could easily add them to the webpack config, though:

// gatsby-node.js
const path = require('path');

const resolve = (pkg) => path.dirname(require.resolve(`${pkg}/package.json`))

exports.onCreateWebpackConfig = ({ actions }) => {
    actions.setWebpackConfig({
        resolve: {
            alias: {
                '@mdx-js/mdx': resolve('@mdx-js/mdx'),
                '@mdx-js/react': resolve('@mdx-js/react'),
            }
        }
    });
}

[Js-Brecht]

However, I think you might be able to solve the issues with @mdx-js/mdx and @mdx-js/react by re-exported the gatsby-plugin-mdx exports:

export { MDXRenderer } from 'gatsby-plugin-mdx';

And import that from the consumer of your plugin? Theoretically, that should take care of the context of @mdx-js/mdx and @mdx-js/react, so long as they are installed as dependencies of your plugin 🤔

[ksjogo]

The onCreateWebpackConfig worked great for pushing the peer dependencies up into my plugin, thank you.

The concrete site is actually not using the MDXRenderer directly, as all the templates are provided by my plugin.

I am not sure what you mean with "those loaders should be resolved to absolute paths" as they already are in that format currently.

gatsby/packages/gatsby-plugin-mdx/gatsby/create-webpack-config.js

Line 50 in 4043129

loader: path.join(`gatsby-plugin-mdx`, `loaders`, `mdx-scopes`),

gatsby/packages/gatsby-plugin-mdx/wrap-root-element.js

Line 26 in 4043129

import { plugins as mdxPlugins } from "./loaders/mdx-components"

[Js-Brecht]

The concrete site is actually not using the MDXRenderer directly, as all the templates are provided by my plugin.

Maybe it would help to see your repo, or a simplified example.

I am not sure what you mean with "those loaders should be resolved to absolute paths" as they already are in that format currently.

FS absolute, not “Node” absolute. Using a (real) absolute path means Webpack doesn’t have to do any resolution to find the file.

[github-actions]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[github-actions]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community! 💪💜