gatsby: [gatsby-plugin-mdx]: Double images / blurry / wrong style

So digging a little deeper, it looks like Gatsby only looks for “subplugins” at one specific path, options.plugins.

gatsby-plugin-mdx uses options.gatsbyRemarkPlugins. This is fine for transforming markdown as the plugin handles that itself, but Gatsby-specific api files like gatsby-browser.js don’t get loaded because Gatsby doesn’t know they exist.

If you try this…

    {
      resolve: 'gatsby-plugin-mdx',
      options: {
        gatsbyRemarkPlugins: [ `gatsby-remark-images` ],
        plugins: [ `gatsby-remark-images` ],
      }
    },

…everything works as it should.

Okay, I’ve tracked it down. Here’s a repo.

I think this is a problem with gatsby-plugin-mdx, not gatsby-remark-images, and c4a7c40d63538704f8964cdeb1df8a04285e9b21 just made it visible.

My guess is that gatsby-plugin-mdx isn’t properly loading/running the gatsby api calls made by gatsby-remark-images.

If you configure both gatsby-plugin-mdx and gatsby-transformer-remark to use gatsby-remark-images as a plugin, then everything works as expected.

    ...
    {
      resolve: `gatsby-transformer-remark`,
      options: {
        plugins: [ `gatsby-remark-images` ],
      }
    },
    {
      resolve: 'gatsby-plugin-mdx',
      options: {
        gatsbyRemarkPlugins: [ `gatsby-remark-images` ],
      }
    },

If you don’t use gatsby-remark-images as a gatsby-transformer-remark plugin, or don’t use gatsby-transformer-remark at all, then we see our issue.

    ...
    {
      resolve: `gatsby-transformer-remark`,
      // options: {
      //   plugins: [ `gatsby-remark-images` ],
      // }
    },
    {
      resolve: 'gatsby-plugin-mdx',
      options: {
        gatsbyRemarkPlugins: [ `gatsby-remark-images` ],
      }
    },

@citypaul Your config is not perfect if you use with round images

After finding some references, this is the config that works for me, by declaring gatsby-remark-images config one more time outside of MDX plugin’s options.

{
  resolve: `gatsby-plugin-mdx`,
  options: {
    extensions: ['.mdx', '.md'],
    defaultLayouts: {
      default: path.join(__dirname, './src/templates/markdown-page.js'),
    },
    gatsbyRemarkPlugins: [
      {
        resolve: `gatsby-remark-images`,
        options: {
          maxWidth: 860,
          backgroundColor: 'none',
        },
      },
    ],
  },
},
{
  resolve: `gatsby-remark-images`,
  options: {
    maxWidth: 860,
    backgroundColor: 'none',
  },
},

I can confirm that this happens to my site when updating gatsby-remark-images from 3.1.2 to 3.1.3.

@rwieruch if you add the styles back, I think things will look they way they did before.

.gatsby-resp-image-image {
  width: 100%;
  height: 100%;
  margin: 0;
  vertical-align: middle;
  position: absolute;
  top: 0;
  left: 0;
}

The problem isn’t with .gatsby-resp-image-background-image, it’s that the img after it should be absolutely positioned and it no longer is.

Hm, this seems to still be an active bug, at least when using with gatsby-remark-images-medium-zoom.

I still needed to duplicate the plugin also to the plugins option key - didn’t work without it being both in plugins and gatsbyRemarkPlugins:

https://github.com/JaeYeopHan/gatsby-remark-images-medium-zoom/pull/13

@rwieruch maybe consider reopening?

This issue has gotten some visibility as a single point of reference for this bug, and is even referred to in some starters:

https://github.com/hagnerd/gatsby-starter-blog-mdx/blob/fb1966a296bbfd9f5f06e2d065705b97f1cb123b/gatsby-config.js#L30-L31

@ChristopherBiscardi thank you for the detailed explanation. And thank you for all of the work on MDX in Gatsby!

You’ve made the point a few times that using MDX obviates the need for a bunch of the gatsby-remark plugins.

I’m kind of in over my head here, but I think a fourth option would be to just drop support for gatsby-remark-* plugins.

I’ve looked at your autolink-header and prism replacements at gatsby-mdx. It looks like they just inject components. As you envision them, do gatsby-mdx-* plugins ever touch the AST?

What if gatsby-mdx-* plugins optionally exported transformRemark and transformRehype functions which could be added to the transformation pipeline? You could do a transformation and inject a component in the same plugin.

---

All I really want out of gatsby-remark-images is to turn something like this

![my image](./images/my-image.jpg)

into something like this

<GatsbyImage fluid={/* image data generated from my-image.jpg */} />

If we could use variables in static queries then I wouldn’t need a plugin. I could just write my own component around gatsby-image and import it directly in my mdx files.

In lieu of that, I could do what gatsby-remark-images does, but instead of inserting hardcoded html I could insert jsx and map it to GatsbyImage.

I wrote a simple plugin that does this and loaded it as a vanilla gatsbyRemark plugin, then included GatsbyImage as a component in MDXProvider. It’s naive but it gets the job done.

If gatsby-mdx-* plugins could touch the AST then something like this could be bundled into a nice replacement for gatsby-remark-images.

I think the solution is to ensure that gatsby-plugin-mdx is loading plugins properly. However, there’s a lot going on in the plugin and much of it is over my head.

@ChristopherBiscardi, am I understanding the problem correctly? Is it reasonable to just rename gatsbyRemarkPlugins as plugins?

Yesterday I updated to the recent Gatsby versions and I was able to remove the workaround code. I think this is fixed.

@cwgw Thanks for narrowing this down (and to everyone else who helped). Gatsby’s handling of sub-plugins has always been special but I suppose it matters more now than it used to with the recent gatsby-remark-plugin release.

The flattenedPlugins list that gets plugged into the redux store won’t have the gatsbyRemarkPlugins from the gatsby-plugin-mdx options because support for sub-plugins using the plugins API key is hard-coded into the load-plugins function (https://github.com/gatsbyjs/gatsby/blob/a364c3d8fb4a8bfe39bad6f203f2ea5218adaa31/packages/gatsby/src/bootstrap/load-plugins/index.js#L20-L38), which is why when the api-runner-ssr goes to execute the gatsby-ssr functions from that earlier commit (onRenderBody), it doesn’t find it unless the plugin is also specified in plugins. gatsby-plugin-mdx technically uses the plugins array for a prototype shortcodes and components sub-plugin supply implementation in it’s wrapRootElement, but gatsby-remark-images is a no-op for the files gatsby-plugin-mdx uses for that so the double-inclusion happens to work in the gatsby-config.

SO, I’m not sure what the best option is here. Adding support to load-plugins to load alternative keys like gatsbyRemarkPlugins seems like unnecessary complexity since gatsby-plugin-mdx is the only plugin that I’m aware of that loads additional plugins like this. So additional complexity in core for one use case is a bit meh.

The other option is to move gatsbyRemarkPlugins to operate out of plugins. This has the downside of being a technically breaking change (even though it can be done backward compatibly) and means we can’t use the plugins array for gatsby-mdx specific plugins (because we do some API smoothing over to run gatsbyRemark plugins as remark plugins and that turns out to be a bit complicated where we need to do things like pass in pieces of the node system and such).

I think something that could have a large impact on this might be to work the gatsby-remark-* plugin API surface back into compatibility with the regular remark plugins, which would also have the benefit of unifying the ecosystem again. That would make our gatsbyRemarkPlugin compat support layer unnecessary and we could entertain overlaying the remark plugin… but I haven’t had a chance to work deeply on this yet, it is a big chunk of work, and will also possibly not totally solve the problem here.

---

I wonder what @gatsbyjs/core thinks about enabling arbitrarily keyed sub-plugins (see below for pseudo-code where a, b, and c would contain gatsby-ssr, etc files) to participate in the gatsby-* runners.

module.exports = {
  plugins: [{
    resolve: `gatsby-plugin-mdx`,
    options: {
      subPlugins: [`a`, `b`, `c`]
    }
  }]
}

I am experiencing this same issue. Is the only solution to us cwgw’s snippet?

Thank you for your help. I’ll try to isolate the issue with a repo.

@DavidSabine which workaround are you using? The what does your Gatsby configuration look like 1) before (with the workaround) and 2) now (without the workaround)?

Hi @karlhorky, thanks for the question. My comment was cryptic I suppose.

So: FIRST, note that my gatsby site inherits gatsby-remark-images from gatsby-theme-blog-core. So a couple of the ‘workarounds’ above (in gatsby-config.js) I’ve avoided.

I used styles to workaround the problem.

span.gatsby-resp-image-background-image {
    padding-bottom: 0 !important;
}

That seemed to do the trick.

On January 17th I noticed that all the images in my blog had disappeared. (https://scrum.works/articles) In fact, they had height of zero pixels (and my padding-bottom override was preventing span.gatsby-resp-image-wrapper from expanding to the height of the image. (gatsby-image-remark uses padding-bottom: x% (where x is a ratio of the image’s width) to control the height of the container.

Yesterday, I removed my workaround and, voila!, images appear normally now. So, I wonder if others in this thread have observed a major change lately in the output of this plugin.

I had an issue just now where Images pulled in with mdx files were still showing the blur. Here’s a screenshot:

The above screenshot was generated using this config:

 "gatsby-transformer-remark",
    {
      resolve: "gatsby-plugin-mdx",
      options: {
        extensions: [".mdx", ".md"],
        gatsbyRemarkPlugins: [
          {
            resolve: `gatsby-remark-images`,
            options: {
              maxWidth: 1200,
              linkImagesToOriginal: false
            }
          }
        ]
       }
    },

Simply adding the plugins key fixes it:

Final config:

  "gatsby-transformer-remark",
    {
      resolve: "gatsby-plugin-mdx",
      options: {
        extensions: [".mdx", ".md"],
        gatsbyRemarkPlugins: [
          {
            resolve: `gatsby-remark-images`,
            options: {
              maxWidth: 1200,
              linkImagesToOriginal: false
            }
          }
        ],
        plugins: ["gatsby-remark-images"]
      }
    },

However, I couldn’t find any reference to this in the docs (and I’m not sure if this is a good solution as it seems like a bit of a hack?)

You’ve made the point a few times that using MDX obviates the need for a bunch of the gatsby-remark plugins.

I’m kind of in over my head here, but I think a fourth option would be to just drop support for gatsby-remark-* plugins.

We can’t deprecate support because that means migration for people using gatsby-transformer-remark becomes harder. We still want switching costs from remark to mdx to be very low and people to replace their gatsby-remark-* plugins at a pace and time that works for them.

Also gatsby-remark-images is one of the few plugins that gatsby-mdx can not replicate without StaticQuery variables, which will come eventually but don’t currently exist.

I’ve looked at your autolink-header and prism replacements at gatsby-mdx. It looks like they just inject components. As you envision them, do gatsby-mdx-* plugins ever touch the AST?

We could likely allow gatsby-mdx-* plugins to add plugins to the remarkPlugins and rehypePlugins lists. This is a bit farther out since we have to solve the current gatsbyRemark backward compat support first. (the gatsby-mdx plugins were, and still are a prototype that is dark-shipped, so there’s more work to do).

@KyleAMathews

The goal is to enable plugins to create their own sub-plugin ecosystem that works however makes sense for it while still letting these sub-plugins take advantage of Gatsby APIs.

cc/ @sidharthachatterjee with whom I was discussing this the other day. Should I create a new issue to track this? Seems like we have a couple options for how to do it. If we enable this, then we would also be able to enable remark-* plugins to use gatsby apis, getting us one step closer to having a solution where gatsby-remark-* plugins can be transparently used in the same place as remark plugins.

it looks like gatsby-remark-images is supposed to add the .gatsby-resp-image-image styles back in via a style tag in the head

Yep, it’s supposed to. The commit message mentions the rationale. I’m sorry to hear this isn’t working for you, I will try to help find a resolution.

Could the problem be a conflict with gatsby-plugin-mdx?

Possibly, I haven’t used gatsby-plugin-mdx myself. I had a quick look and it doesn’t seem to use the replaceRenderer API, so I’m not sure why the head component I added wouldn’t be rendered.

Is there a starter or public repository that reproduces the problem?