Explore moving to babel standalone or offering a more browser friendly build #704
Labels
💪 phase/solved
Post is done
💬 type/discussion
This is a request for comments
🦋 type/enhancement
This is great to have
💎 v2
Issues related to v2
Milestone
Comments
johno
added
🦋 type/enhancement
This was referenced Aug 2, 2019
johno
added a commit
that referenced
this issue
Aug 9, 2019
Though it isn't recommended, MDX often finds itself being used on the client or other environmentts where bundler configuration might not be customizable. This switches to babel standalone to allow for better support for those scenarios. Before actually merging this it might be worthwhile to add some benchmarking to ensure that this doesn't introduce a performance regression (I'm not sure how standalone works internally). --- Closes #704
johno
added a commit
that referenced
this issue
Sep 10, 2019
Though it isn't recommended, MDX often finds itself being used on the client or other environmentts where bundler configuration might not be customizable. This switches to babel standalone to allow for better support for those scenarios. Before actually merging this it might be worthwhile to add some benchmarking to ensure that this doesn't introduce a performance regression (I'm not sure how standalone works internally). --- Closes #704
johno
added
💪 phase/solved
wooorm
added
🙆 yes/confirmed
|
Is this available in @mdx-js/mdx@2.0.0-next.1? If not, is there any estimate for its release? I'm curious to know how much improvement this will make in my bundle size |
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 20, 2020
This removes the last three custom Babel plugins we had and replaces them with estree versions. Furthermore, it removes `@babel/generator`. For the plugins, we were only looking at ESM import/exports, but right now we’re delegating work to `periscopic` to look at which things are defined in the top-level scope. It’s a bit more complex, but this matches better with intentions, fixes some bugs, and prepares for a potential future where other ES constructs are allowed, so all in all should be a nice improvement. For serializing, we’re switching to `astring`, and handling JSX for now internally (could be externalized later). `astring` seems fast and is incredibly small, but is not very popular. We might perhaps see bugs is serialization in the future because of that, but all our tests seem fine, so I’m not too worried about that. Estree remains a somewhat fragmented ecosystem, such as that the tree walkers in `periscopic` and `astring` are different, so we might also consider writing our own serializer in the future. Or, when we implement Babel’s React JSX transform ourselves, could switch to another generator, or at least drop the JSX serialization code here. Because of these changes, we can drop `@babel/core` and `@babel/generator` from `@mdx-js/mdx`, which drops the bundle size of from 349kb to 111kb. That’s 68%. Pretty nice. This should improve downloading and parsing time of bundles significantly. Of course, we currently still have JSX in the output, so folks will have to resort to Babel (or `buble-jsx-only`) in another step. For performance, v2 (micromark) was already an improvement over v1. On 1000 simple files totalling about 1mb of MDX: * v1: 3739ms * v2: 2734ms (26% faster) * v2 (w/o babel): 1392ms (63% faster). Of course, this all really depends on what type of stuff is in your MDX. But it looks pretty sweet! ✨ Related to GH-1046. Related to GH-1152. Related to GH-1338. Closes GH-704. Closes GH-1384.
johno
pushed a commit
that referenced
this issue
Dec 20, 2020
This removes the last three custom Babel plugins we had and replaces them with estree versions. Furthermore, it removes `@babel/generator`. For the plugins, we were only looking at ESM import/exports, but right now we’re delegating work to `periscopic` to look at which things are defined in the top-level scope. It’s a bit more complex, but this matches better with intentions, fixes some bugs, and prepares for a potential future where other ES constructs are allowed, so all in all should be a nice improvement. For serializing, we’re switching to `astring`, and handling JSX for now internally (could be externalized later). `astring` seems fast and is incredibly small, but is not very popular. We might perhaps see bugs is serialization in the future because of that, but all our tests seem fine, so I’m not too worried about that. Estree remains a somewhat fragmented ecosystem, such as that the tree walkers in `periscopic` and `astring` are different, so we might also consider writing our own serializer in the future. Or, when we implement Babel’s React JSX transform ourselves, could switch to another generator, or at least drop the JSX serialization code here. Because of these changes, we can drop `@babel/core` and `@babel/generator` from `@mdx-js/mdx`, which drops the bundle size of from 349kb to 111kb. That’s 68%. Pretty nice. This should improve downloading and parsing time of bundles significantly. Of course, we currently still have JSX in the output, so folks will have to resort to Babel (or `buble-jsx-only`) in another step. For performance, v2 (micromark) was already an improvement over v1. On 1000 simple files totalling about 1mb of MDX: * v1: 3739ms * v2: 2734ms (26% faster) * v2 (w/o babel): 1392ms (63% faster). Of course, this all really depends on what type of stuff is in your MDX. But it looks pretty sweet! ✨ Related to GH-1046. Related to GH-1152. Related to GH-1338. Closes GH-704. Closes GH-1384.
wooorm
added
💪 phase/solved
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since
@babel/coreattempts to bring along thefsmodule we're often forced to do annoying webpack config and other hacks.For environments where that control might not exist we should look into using
@babel/standaloneor even offering an@mdx-js/standalonethat things like@mdx-js/runtimecould use.The text was updated successfully, but these errors were encountered: