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

Support Class and decorator #1028

Closed
YuunYang opened this issue Apr 23, 2020 · 6 comments · Fixed by #1382
Closed

Support Class and decorator #1028

YuunYang opened this issue Apr 23, 2020 · 6 comments · Fixed by #1382
Labels
🙉 open/needs-info This needs some more info 🦋 type/enhancement This is great to have

Comments

@YuunYang
Copy link

YuunYang commented Apr 23, 2020

Subject of the feature

Support writing decorator and class in MDX file

Problem

Now, if I want to write class or decorator in mdx file, it will report an error. maybe we need add a feature to enable those grammar

Like if I write a class in mdx file it will throw an error from '@mdx-js/loader/index.js':
Support for the experimental syntax 'classProperties' isn't currently enabled,

It is actually not a bug in mdx, but a problem caused by lack of babel-loader plugin, I have tried to add those plugins in mdx/mdx-hast-to-jsx.js, solved those errors but caused another error -.-
image

Expected behavior

Now, the mdx seems not support class declaration and other experimental syntax, So I want mdx to support more experimental

Alternatives

No alternatives

@YuunYang YuunYang added 🙉 open/needs-info This needs some more info 🦋 type/enhancement This is great to have labels Apr 23, 2020
@wooorm
Copy link
Member

wooorm commented Apr 23, 2020

Could you fill out expected behavior and alternatives? Could you provide example code of what you’d like to be supported?

@YuunYang
Copy link
Author

@wooorm Thanks for attention, I just updated the text

@wooorm
Copy link
Member

wooorm commented Apr 24, 2020

Thanks. Is this issue about:

  1. Allowing fancy new features in MDX, by letting you define your own Babel plugins?
  2. These two features specifically?

@YuunYang
Copy link
Author

Yes, because some experimental feature is used in many times, and it is much better if we can add custom babel or other configs

@wooorm
Copy link
Member

wooorm commented Apr 28, 2020

Alright, so I’m assuming you want a solution to 1) instead of 2).

There are some caveats with solving this because some parts of the babel config are required for MDXjs to work, so we can’t give users all control.

@wooorm
Copy link
Member

wooorm commented Nov 13, 2020

Hi @YuunYang, thanks for your patience!

The MDX loader is used alongside babel: https://github.com/mdx-js/mdx/tree/master/packages/loader. Have you tried configuring that?

To dig into this some more, I’d appreciate if you could update your issue with a minimal reproduction: something that a maintainer or contributor can run to reproduce your problem. Thanks!

wooorm added a commit that referenced this issue Dec 11, 2020
This updates MDX to use and support remark@13, which comes with a new internal
parser (micromark), and supports CommonMark.
See <https://github.com/remarkjs/remark/releases/tag/13.0.0> for more
information.
In short, this means MDX parses markdown closer to what folks expect.
And it means all latest plugins work (again).

But it also means that parsing MDX syntax (JSX, expressions, ESM) got an update.
See: <https://github.com/micromark/micromark-extension-mdxjs> and
<https://github.com/syntax-tree/mdast-util-mdx> for the syntax.
In short, this means MDX parsing is now JavaScript-aware: import/exports are
actually parsed for being valid JavaScript.
Expressions previously counted braces, but now can include braces in strings or
comments or whatnot.
This also means we can drop Babel (in a future PR) because we already have a
JavaScript AST.

This also deprecates the packages `remark-mdxjs` (which is now the default in
`remark-mdx`), `remark-mdx-remove-exports`, and `remark-mdx-remove-imports`.

Related to GH-704.
Related to GH-1041.

Closes GH-720.
Closes GH-1028.
Closes GH-1050.
Closes GH-1081.
Closes GH-1193.
Closes GH-1238.
Closes GH-1283.
Closes GH-1316.
Closes GH-1318.
Closes GH-1341.
wooorm added a commit that referenced this issue Dec 15, 2020
This updates MDX to use and support remark@13, which comes with a new internal
parser (micromark), and supports CommonMark.
See <https://github.com/remarkjs/remark/releases/tag/13.0.0> for more
information.
In short, this means MDX parses markdown closer to what folks expect.
And it means all latest plugins work (again).

But it also means that parsing MDX syntax (JSX, expressions, ESM) got an update.
See: <https://github.com/micromark/micromark-extension-mdxjs> and
<https://github.com/syntax-tree/mdast-util-mdx> for the syntax.
In short, this means MDX parsing is now JavaScript-aware: import/exports are
actually parsed for being valid JavaScript.
Expressions previously counted braces, but now can include braces in strings or
comments or whatnot.
This also means we can drop Babel (in a future PR) because we already have a
JavaScript AST.

This also deprecates the packages `remark-mdxjs` (which is now the default in
`remark-mdx`), `remark-mdx-remove-exports`, and `remark-mdx-remove-imports`.

Related to GH-704.
Related to GH-1041.

Closes GH-720.
Closes GH-1028.
Closes GH-1050.
Closes GH-1081.
Closes GH-1193.
Closes GH-1238.
Closes GH-1283.
Closes GH-1316.
Closes GH-1318.
Closes GH-1341.
Closes GH-1367.

Reviewed-by: Christian Murphy <christian.murphy.42@gmail.com>
wooorm added a commit that referenced this issue Dec 15, 2020
This PR changes the internals of the core `@mdx-js/mdx` package to generate a
JavaScript syntax tree instead of a string.
This fixes escaping issues such as #1219.
It makes `mdx-hast-to-jsx` much more palatable.
It also prevents several Babel parses.
It paves the way for passing in Babel plugins, which is useful for users, but
also for us to compile to `React.createElement`, `_jsx`, or Vue’s `h` calls
directly and make MDX’s output directly usable.

* `babel-plugin-apply-mdx-type-props`: add `parentType`
* `mdx`: use `rehype-minify-whitespace` to remove superfluous whitespace
* `mdx`: use `hast-util-to-estree` to transform hast to estree
* `mdx`: use `estree-to-babel` to transform estree to Babel
* `mdx`: generate estree/Babel instead of strings
* `mdx`: use `@babel/generator` to serialize Babel AST
* `vue`: stop supporting the react transform: (it doesn’t make sense)
* `vue`: fix support for props to components

Related to GH-741.
Related to GH-1152.

Closes GH-606.
Closes GH-1028.
Closes GH-1219.
wooorm added a commit that referenced this issue Dec 18, 2020
This PR changes the internals of the core `@mdx-js/mdx` package to generate a
JavaScript syntax tree instead of a string.
This fixes escaping issues such as #1219.
It makes `mdx-hast-to-jsx` much more palatable.
It also prevents several Babel parses.
It paves the way for passing in Babel plugins, which is useful for users, but
also for us to compile to `React.createElement`, `_jsx`, or Vue’s `h` calls
directly and make MDX’s output directly usable.

* `babel-plugin-apply-mdx-type-props`: add `parentType`
* `mdx`: use `rehype-minify-whitespace` to remove superfluous whitespace
* `mdx`: use `hast-util-to-estree` to transform hast to estree
* `mdx`: use `estree-to-babel` to transform estree to Babel
* `mdx`: generate estree/Babel instead of strings
* `mdx`: use `@babel/generator` to serialize Babel AST
* `vue`: stop supporting the react transform: (it doesn’t make sense)
* `vue`: fix support for props to components

Related to GH-741.
Related to GH-1152.

Closes GH-606.
Closes GH-1028.
Closes GH-1219.
wooorm added a commit that referenced this issue Dec 18, 2020
This PR changes the internals of the core `@mdx-js/mdx` package to generate a
JavaScript syntax tree instead of a string.
This fixes escaping issues such as #1219.
It makes `mdx-hast-to-jsx` much more palatable.
It also prevents several Babel parses.
It paves the way for passing in Babel plugins, which is useful for users, but
also for us to compile to `React.createElement`, `_jsx`, or Vue’s `h` calls
directly and make MDX’s output directly usable.

* `babel-plugin-apply-mdx-type-props`: add `parentType`
* `mdx`: use `rehype-minify-whitespace` to remove superfluous whitespace
* `mdx`: use `hast-util-to-estree` to transform hast to estree
* `mdx`: use `estree-to-babel` to transform estree to Babel
* `mdx`: generate estree/Babel instead of strings
* `mdx`: use `@babel/generator` to serialize Babel AST
* `vue`: stop supporting the react transform: (it doesn’t make sense)
* `vue`: fix support for props to components

Related to GH-741.
Related to GH-1152.

Closes GH-606.
Closes GH-1028.
Closes GH-1219.
Closes GH-1382.

Reviewed-by: Christian Murphy <christian.murphy.42@gmail.com>
wooorm added a commit that referenced this issue Dec 18, 2020
This PR changes the internals of the core `@mdx-js/mdx` package to generate a
JavaScript syntax tree instead of a string.
This fixes escaping issues such as #1219.
It makes `mdx-hast-to-jsx` much more palatable.
It also prevents several Babel parses.
It paves the way for passing in Babel plugins, which is useful for users, but
also for us to compile to `React.createElement`, `_jsx`, or Vue’s `h` calls
directly and make MDX’s output directly usable.

* `babel-plugin-apply-mdx-type-props`: add `parentType`
* `mdx`: use `rehype-minify-whitespace` to remove superfluous whitespace
* `mdx`: use `hast-util-to-estree` to transform hast to estree
* `mdx`: use `estree-to-babel` to transform estree to Babel
* `mdx`: generate estree/Babel instead of strings
* `mdx`: use `@babel/generator` to serialize Babel AST
* `vue`: stop supporting the react transform: (it doesn’t make sense)
* `vue`: fix support for props to components

Related to GH-741.
Related to GH-1152.

Closes GH-606.
Closes GH-1028.
Closes GH-1219.
Closes GH-1382.

Reviewed-by: Christian Murphy <christian.murphy.42@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🙉 open/needs-info This needs some more info 🦋 type/enhancement This is great to have
Development

Successfully merging a pull request may close this issue.

2 participants