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

Using mdx in @next #5149

Open
eckdanny-osi opened this Issue Sep 28, 2018 · 7 comments

Comments

Projects
None yet
4 participants
@eckdanny-osi

eckdanny-osi commented Sep 28, 2018

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

This comment has been minimized.

Show comment
Hide comment
@eckdanny-osi

eckdanny-osi Sep 28, 2018

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

eckdanny-osi commented Sep 28, 2018

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 Timer added this to the 2.0.0 milestone Sep 28, 2018

@Timer

This comment has been minimized.

Show comment
Hide comment
@Timer

Timer Sep 28, 2018

Collaborator

@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');
Collaborator

Timer commented Sep 28, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Sep 28, 2018

Member

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

Member

gaearon commented Sep 28, 2018

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

@gaearon gaearon referenced this issue Sep 28, 2018

Closed

react-scripts@2 final blockers #5141

19 of 25 tasks complete
@eckdanny-osi

This comment has been minimized.

Show comment
Hide comment
@eckdanny-osi

eckdanny-osi Sep 28, 2018

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.

eckdanny-osi commented Sep 28, 2018

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

This comment has been minimized.

Show comment
Hide comment
@Timer

Timer Sep 29, 2018

Collaborator

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

Collaborator

Timer commented Sep 29, 2018

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

@sw-yx

This comment has been minimized.

Show comment
Hide comment
@sw-yx

sw-yx Oct 6, 2018

Contributor

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.

Contributor

sw-yx commented Oct 6, 2018

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

This comment has been minimized.

Show comment
Hide comment
@Timer

Timer Oct 6, 2018

Collaborator

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.

Collaborator

Timer commented Oct 6, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment