AST node name changes in next.9

Subject of the issue

The new node types in v2-next.9 renames the types

• export
• import
• jsx

into

• mdxjsEsm
• mdxJsxFlowElement

I believe a full list of the 5 new node types can be found here

The new node types for import and export specifically seem to mostly be additive changes (specifically, inserting the new estree AST as data on the node), but the name change will break gatsby-plugin-mdx and anyone else who is depending on the export or import nodes (as well as the jsx node).

Also note that the behavior here is slightly different. An import and an export next to each other are now combined into a single mdxjsEsm node.

Your environment

• Packages: @mdx-js/mdx@^2.0.0-next.9

Steps to reproduce

const mdx = require("@mdx-js/mdx");

main();

async function main() {
  const t = mdx.createCompiler().parse(string);

  const f = await mdx.createCompiler().parse(`
import Thing from 'somewhere';
export const meta = {};

<Test/>
`);
  console.log(f);
}

Expected behaviour

Expected import node and export node to be separate and include one import or export per node.

Actual behaviour

both import and export are combined into a single new node type, even though the .value string still exists and would provide backwards compatibility.

{
  type: 'root',
  children: [
    {
      type: 'mdxjsEsm',
      value: "import Thing from 'somewhere';\nexport const meta = {};",
      position: [Object],
      data: [Object]
    },
    {
      type: 'mdxJsxFlowElement',
      name: 'Test',
      attributes: [],
      children: [],
      position: [Object]
    }
  ],
  position: {
    start: { line: 1, column: 1, offset: 0 },
    end: { line: 6, column: 1, offset: 65 }
  }
}

Additional questions

Is it also possible to provide backwards compatibility for the jsx node?

[johno]

Ah I see, I suppose we can get close to current support by exposing some APIs for walking the estree for folks that want to do things like plucking/removing imports and specific types of exports.

[wooorm]

The reason for having a single node that contains arbitrary JavaScript is a) in alignment with how it’s parsed, but importantly b), to allow extensions to what’s allowed. Such as var/let/const (GH-1046) without adding new nodes (so, in a minor release).

That single arbitrary JS node also allows MDX to be extended to support:

```js eval
var number = Math.PI
```

The number is {number}.

…through a plugin that walks mdast and replaces code[eval] with such an mdxjsEsm node.

Another idea is to allow more vue/svelte like syntax:

<script>
  var number = Math.PI
</script>

The number is {number}.

To answer “they’re semantically […] different” — On the JavaScript level they are. And they are separately available as a subtree. Folks can inspect and transform those subtrees, which is in my opinion preferable over trying to handle a serialized value (such as what remark-mdx-frontmatter does), Exposing the JavaScript in a plugin mechanism is now also a minor release away in @mdx-js/mdx. This would allow arbitrary JavaScript transforms, such as minification (terser) or bundling (what mdx-bundler does currently).