Using mdx in @next

[eckdanny-osi]

I think many CRA users like myself are using mdx-js/mdx. The mdx docs for CRA setup use create-react-app-rewired, but I've managed just fine in CRA v1.x without ejecting or rewiring by inlining webpack loader and eslint overrides:

/* eslint-disable import/no-webpack-loader-syntax */
import Content from '!babel-loader!@mdx-js/loader!./Content.mdx';

I tried the same course of action in @2.0.0 but its not working for reasons I haven't looked into yet. (I'll leave details in a comment below. Raising at mdx-js may be appropriate.)

THE REASON I'm submitting this issue is to identify MDX usage as a likely reason for ejecting/rewiring in response to @Timer's comment timarney/react-app-rewired#162 (comment). The future support outlook for rewired and missing workaround for CRA@next is unfortunate for MDX users.

[eckdanny-osi]

The err I mentioned in OP:

Failed to compile.

./src/Content.mdx)
Syntax error: <cra@next>/src/Content.mdx: Unexpected token (6:43)

  4 |
  5 |
> 6 | export default ({components, ...props}) => <MDXTag name="wrapper"  components={components}><MDXTag name="p" components={components}>{`hi`}</MDXTag></MDXTag>
    |                                            ^
  7 |

Not sure what's root cause... Odd to me the same inline-loader syntax in app code and same version of mdx-js/loader/mdx-js/mdx behaves differently in my CRA v1.x and CRA v2.0.0

[Timer]

@gaearon should we support this natively or via a babel macro?

If natively, when imported via import Content from './Content.mdx'; or only when import { ReactComponent as Content } from './Content.mdx';?

Macro would work like so:

import { mdx } from 'mdx.macro'
const Content = mdx('./Content.mdx');

[gaearon]

Macro is nice if it means we don’t have to include MDX compiler by default.

[eckdanny-osi]

Tnx guys, I hadn't yet been introduced to babel-plugin-macros (which is amazing).

The usage hinted at above and expectation that users be responsible for satisfying a dep on mdx-js/mdx compiler seem perfectly appropriate to me.

next steps: shall I open an an issue with the @mdx-js/* repo maintainers to seeking provision of a @mdx-js/macro or mdx.macro package? (If the tech impl sol'n space is not in CRA then maybe this issue can be closed.)

I'm happy CRA@next is providing an escape hatch for these sorts of things.

[Timer]

We should ask for a @mdx-js/macro or mdx.macro package!

[swyxio]

hi! just browsing. i am not sure i understand what exactly the macro would solve for you since @eckdanny-osi's original problem was that the webpack loader inlining was broken. the macro won't be able to do anything to fix that. maybe we can open an issue over at @mdx-js and follow on from there.

[Timer]

original problem was that the webpack loader inlining was broken

Using the method displayed in OP is not supported by CRA and never expected to work.
MDX support will only be allowed via a Babel Macro, thus the suggestion.

[eckdanny-osi]

hey guys. sry haven't checked back in on this convo in a while.

My project is back to using webpack's inline-loader syntax w/ react-scripts@2.0.4. Only having *just discovered babel-plugin-macros when i 1st posted, I had hoped they would be enough escape hatch, but @sw-yx is right. My project could impl some one-off macros using @mdx-js/mdx (e.g.; parse and compile small snippets to JSX), but what we really need/want is to tap into the loader chain.

We were on react-scripts-cssmodules before CRA@2 shipped. I guess I imagined the path to support MDX in CRA and the developer end-user experience would be similar to the sass support story. (webpack plumbing is there for us, but we must add the compiler to use it like the CLI and docs say for sass)

If my project hits more walls we can't circumnavigate with inline-loader syntax, we'll likely eject or maintain a fork. Don't know how unique my situation is... am curious to what degree CRA users want mdx support tho