Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forwarding options to remarkPlugins/rehypePlugins can break them #575

Closed
silvenon opened this issue May 12, 2019 · 6 comments · Fixed by #576
Closed

Forwarding options to remarkPlugins/rehypePlugins can break them #575

silvenon opened this issue May 12, 2019 · 6 comments · Fixed by #576
Labels
🐛 type/bug This is a problem

Comments

@silvenon
Copy link
Contributor

silvenon commented May 12, 2019

Subject of the issue

Currently @mdx-js/mdx forwards its options to every plugin in remarkPlugins and rehypePlugins, which can easily lead to some of them breaking. Is there a specific reason why we're doing this? If it's a behavior left over from something else, I can remove it.

Your environment

  • Name and version of operating system: macOS 10.14.4
  • Names and version of required packages: 1.0.18
  • Version of node, npm, yarn, or names and versions of browser: yarn 1.16.0

Steps to reproduce

import mdx from '@mdx-js/mdx'
import detectFrontmatter from 'remark-frontmatter'

const content = `
---
title: Hello World!
---
`

mdx(content, {
  remarkPlugins: [
    detectFrontmatter,
  ],
})

Expected behaviour

remark-frontmatter shouldn't be getting unexpected options.

Actual behaviour

Options from the mdx() call get forwarded to remark-frontmatter, which thinks we're passing the definition for detecting frontmatter, but the shape of the object doesn't satisfy its criteria so it crashes.

Temporary workaround

Passing undefined as an option to all plugins, which results in default, i.e. expected behavior.

mdx(content, {
  remarkPlugins: [
    [detectFrontmatter, undefined],
  ],
})
@silvenon silvenon added the 🐛 type/bug This is a problem label May 12, 2019
@wooorm
Copy link
Member

wooorm commented May 13, 2019

Funky, yeah I’m wondering what the reason is. Seems to be there since the beginning: 587477d

@silvenon
Copy link
Contributor Author

Yeah, I doubt any reason can justify this behavior, so I'll prepare a PR just in case.

@wooorm
Copy link
Member

wooorm commented May 13, 2019

I’m pretty sure a PR is good, but wondering what @johno thinks.

This also could be, very very theoretically, breaking. But it’s much more likely that it breaks plugins like you describe. So I’d say this shouldn’t need a major semver release.

@johno
Copy link
Member

johno commented May 13, 2019

Yeah this is really an artifact of a quick hack that was never cleaned up. I think this is okay without a major since it's likely breaking plugins, but not 100% sure there.

@wooorm
Copy link
Member

wooorm commented May 13, 2019

I suspect there is a teeny tiny extremely slim chance someone depends and we’d break something if we patch it up. If we do a major (or wait for one) the chance of someone being on ^1.0.0 and trying to use a plugin that breaks is much much much larger.

I also think @silvenon has a good enough understanding of remark and MDX that he can figure out what happened rather easily, but I don’t think many other persons using MDX can figure out what’s failing, resulting in a pretty bad debugging experience.

Therefore I propose patching this up instead of a major release. We can add a note about this in releases though.

@johno
Copy link
Member

johno commented May 13, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 type/bug This is a problem
Development

Successfully merging a pull request may close this issue.

3 participants