docs: update Parcel MDX plugin for MDX 3 #2523

TechQuery · 2024-08-06T20:02:33Z

Initial checklist

I read the support docs
I read the contributing guide
I agree to follow the code of conduct
I searched issues and couldn’t find anything (or linked relevant results below)
If applicable, I’ve added docs and tests

Description of changes

Parcel official MDX plugin is only support MDX 1, so I publish a new plugin for MDX 3.

Signed-off-by: South Drifted <[email protected]>

vercel · 2024-08-06T20:02:38Z

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
mdx	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 6, 2024 8:04pm

codecov-commenter · 2024-08-06T20:07:41Z

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (908ff45) to head (f8cd910).
Report is 45 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #2523   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           23        23           
  Lines         2693      2712   +19     
  Branches         2         2           
=========================================
+ Hits          2693      2712   +19

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

ChristianMurphy · 2024-08-06T20:37:17Z

Thanks for sharing @TechQuery!

General feedback on what gets included in the plugins/guides list:

Some criteria to include packages in this list.

Some documentation with at least some instructions on how to use the package.

A CI job to run tests.

A prepack script and CI job to build the types.

The package should be published to npm.

source: syntax-tree/hast#24 (comment)

It looks like there aren't any types or tests included in the repository.
In addition:

The repository does not include a LICENSE file, it should have a license. I'd recommend MIT.
It looks like the repository uses a mix of npm and pnpm for dependencies and scripts. I'd recommend using only one. I'd recommend npm.
The plugin hard codes some remark and rehype plugins, I'd recommend starting with vanilla MDX out of the box https://github.com/EasyWebApp/Parcel-transformer-MDX/blob/6380b072de8016c060f721afa3f5461f33c6b162/index.js#L53-L59
The plugin does not allow users to specify their own remark and rehype plugins to include, I'd recommend adding this
You are publishing from GHA, I'd recommend adding package provenance https://github.blog/changelog/2023-09-26-npm-provenance-general-availability/
Parcel as of version 2 defaults to the faster SWC transpiler https://parceljs.org/blog/v2/, it looks like this forces MDX through the slower and non-default Babel pipeline https://github.com/EasyWebApp/Parcel-transformer-MDX/blob/6380b072de8016c060f721afa3f5461f33c6b162/index.js#L25-L29

TechQuery · 2024-08-06T21:43:46Z

Thanks for quick reviewing @ChristianMurphy !

It looks like there aren't any types or tests included in the repository.

🚧This is my first Parcel plugin, I'm learning the best practice of developing Parcel plugins with ESM & TS:

I use JSDoc & TS to check JS codes internally, but users won't import it in their codes, so .d.ts isn't required.
I plan to split the Core Logic to a Node.js loader EasyWebApp/Parcel-transformer-MDX#1 to make test scripts easier.

The repository does not include a LICENSE file, it should have a license. I'd recommend MIT.

I added package.json#license field, and forgot to add a LICENSE file. (As an individual coder, I prefer GPLs.)
- fixed in EasyWebApp/Parcel-transformer-MDX@6d5c2d2

It looks like the repository uses a mix of npm and pnpm for dependencies and scripts. I'd recommend using only one. I'd recommend npm.

This package is designed for NPM compatibility, andI use PNPM for developing, so it's no mix-using for users.

The plugin hard codes some remark and rehype plugins, I'd recommend starting with vanilla MDX out of the box https://github.com/EasyWebApp/Parcel-transformer-MDX/blob/6380b072de8016c060f721afa3f5461f33c6b162/index.js#L53-L59

This plugin has the same goal of Parcel - Zero Configuration, so users can write Markdown files as what they do on GitHub immediately.

The plugin does not allow users to specify their own remark and rehype plugins to include, I'd recommend adding this

Because MDX 3 has no official configuration file, so I'm thinking about the configuration schema of my own plugin. I'm glad to have issue or PR submitted for this feature, and hoping a simple design to keep Parcel easy.

You are publishing from GHA, I'd recommend adding package provenance https://github.blog/changelog/2023-09-26-npm-provenance-general-availability/

Thanks for your suggestion! I noticed this update of NPM web-site, and was too busy to learn how to use it.
- fixed in EasyWebApp/Parcel-transformer-MDX@6d5c2d2
- check in https://www.npmjs.com/package/parcel-transformer-mdx#provenance

Parcel as of version 2 defaults to the faster SWC transpiler https://parceljs.org/blog/v2/, it looks like this forces MDX through the slower and non-default Babel pipeline https://github.com/EasyWebApp/Parcel-transformer-MDX/blob/6380b072de8016c060f721afa3f5461f33c6b162/index.js#L25-L29

These lines just aim to find JSX configuration from all kinds of possible files without extra configuration , which recommends TypeScript and is compatible with Babel, this plugin doesn't control the compiler.

ChristianMurphy · 2024-08-06T22:25:18Z

As an individual coder, I prefer GPLs.

I appreciate that, I don't think unified has a strict policy on license type for adoption (cc @wooorm @remcohaszing)
But for wider adoption, I generally recommend licenses that are compatible with Apache 2.0 https://www.apache.org/legal/resolved.html
The GPL and LGPL licenses exclude a lot of projects and organizations from adopting.

This package is designed for NPM compatibility, and I use PNPM for developing, so it's no mix-using for users

I'd still recommend building, testing, and publishing with one.
They layout packages different and have different resolutions for peer and transitive dependencies.
Mixing the two during development could lead to unexpected errors.

Because MDX 3 has no official configuration file, so I'm thinking about the configuration schema of my own plugin. I'm glad to have issue or PR submitted for this feature, and hoping a simple design to keep Parcel easy.

The plugins are remark and rehype based, you could leverage those files, similar to how eslint-mdx does
https://github.com/mdx-js/eslint-mdx?tab=readme-ov-file#mdxremark

I use JSDoc & TS to check JS codes internally, but users won't import it in their codes, so .d.ts isn't required.

Even if they aren't published I'd recommend running tsc to ensure they are valid.

I plan to EasyWebApp/Parcel-transformer-MDX#1 to make test scripts easier.

Sounds good

TechQuery · 2024-08-06T23:52:22Z

The GPL and LGPL licenses exclude a lot of projects and organizations from adopting.

In my opinion, LGPL is designed for libraries, why people keep worrying about it...

I'd still recommend building, testing, and publishing with one.
They layout packages different and have different resolutions for peer and transitive dependencies.
Mixing the two during development could lead to unexpected errors.

PNPM has more strict Dependency Checking, all packages worked in PNPM also work well in NPM & Yarn.

In the other hand, NPM & Yarn have so bad performance, PNPM is saving my life. But I use it only for local Dependency Management & NPM scripts shorthands, all other things are compatible with NPM.

Even if they aren't published I'd recommend running tsc to ensure they are valid.

When I resolve EasyWebApp/Parcel-transformer-MDX#1, I will rewrite the whole project with TypeScript to replace the quick & dirty version (which is made as the reason of long time waiting for Parcel MDX plugin updating).

wooorm · 2024-08-07T10:17:53Z

In my opinion, LGPL is designed for libraries, why people keep worrying about it...

Re license: I would very very strongly recommend going with MIT/ISC/similar. That’s what almost all packages in the JS ecosystem go with. Parcel too. And us. Only if you’d have a ton of knowledge about this, and thought this through, would I recommend going against 99% of the npm packages.
Also, perhaps you’d be interested in the work on licenses here: https://writing.kemitchell.com/, if you don’t know it already.

I am rather bummed that Parcel hasn’t solved this after a couple years. This reflects poorly on the state of Parcel.
Still, this seems like a temporary solution for now, something that will be fixed in the future.
Have you considered keeping the original text and link in place, but adding a note linking to your plugin for now, such as this note for Vite?

TechQuery · 2024-08-07T16:06:18Z

Re license: I would very very strongly recommend going with MIT/ISC/similar. That’s what almost all packages in the JS ecosystem go with. Parcel too. And us. Only if you’d have a ton of knowledge about this, and thought this through, would I recommend going against 99% of the npm packages.

In my mind, GPLs are for powerless individual coders, and others are for powerful companies, universities or foundations.

Until now, no one of open sourcers arounded gives me a clear reason about this, just keeps saying: "Most people use it, so you should use it"... But why? No one knows the logic in it, it doesn't make sense. I will do anything for what makes me believe.

I am rather bummed that Parcel hasn’t solved this after a couple years. This reflects poorly on the state of Parcel.
Still, this seems like a temporary solution for now, something that will be fixed in the future.

Yeah, as a long term user, I'm worrying about the team status of Parcel project. But after using webpack, Snowpack, MicroBundle & Vite, only Parcel make me, teammates and students happy on coding with Zero Configuration design.

Have you considered keeping the original text and link in place, but adding a note linking to your plugin for now, such as this note for Vite?

I thought about that, but it'll be confused for users to find a plugin only support MDX 1.x in MDX 3.x document.

ChristianMurphy · 2024-08-07T18:00:52Z

In my mind, GPLs are for powerless individual coders, and others are for powerful companies, universities or foundations.

Most software is from and for larger organizations and projects.
If your intent is for this to be a toy project for individual developers.
That is fine, but it doesn't need to be in the main documentation.

Until now, no one of open sourcers arounded gives me a clear reason about this, just keeps saying: "Most people use it, so you should use it"... But why? No one knows the logic in it, it doesn't make sense. I will do anything for what makes me believe.

Concisely, Category X licenses, like LGPL, limit how software can be distributed https://www.apache.org/legal/resolved.html#prohibited
The terms get a bit fuzzier when used as a build tool, but it's pretty common for projects to bundle/build on top of build tools, and those would run into the distribution restrictions.

Zero Configuration design

Presets can be created for other build tools and bundlers as well.

confused for users to find a plugin only support MDX 1.x in MDX 3.x document.

I think they'll be more confused if they go out searching for a parcel plugin, see the official one, and don't see it listed in the MDX docs anywhere.

TechQuery · 2024-08-07T20:23:04Z

Most software is from and for larger organizations and projects.
If your intent is for this to be a toy project for individual developers.
That is fine, but it doesn't need to be in the main documentation.

This plugin is came from Individual coders, for but not only for individuals.

And most great Open Source projects were Toy projects at the beginning, such as Linux with GPL v2.

Concisely, Category X licenses, like LGPL, limit how software can be distributed https://www.apache.org/legal/resolved.html#prohibited
The terms get a bit fuzzier when used as a build tool, but it's pretty common for projects to bundle/build on top of build tools, and those would run into the distribution restrictions.

OK, I will do more research.

Presets can be created for other build tools and bundlers as well.

As I know, only Babel has presets, and other bundlers only have a bunch of configuration fields in their documents, which needs users to set them up manually.

I think they'll be more confused if they go out searching for a parcel plugin, see the official one, and don't see it listed in the MDX docs anywhere.

This plugin is a result of my failed searching about MDX 3.x Parcel plugin, the Parcel official document will tell them that they only support MDX 1.x.

ChristianMurphy · 2024-08-07T21:12:34Z

most great Open Source projects were Toy projects at the beginning, such as Linux with GPL v2.

Sure, I agree.
My point is that the MDX docs focuses on projects that have moved above toy project level.

This plugin is [...] only for individuals.

This concerns me a bit.
Many of MDX's adopters are individuals working in/on-behalf of a larger organization.
I'm not saying you have to offer corporate enterprise support.
But excluding all organization based developers feels a step too far to me (personally, not speaking on behalf of other maintainers).

As I know, only Babel has presets, and other bundlers only have a bunch of configuration fields in their documents, which needs users to set them up manually.

Any build tool can be wrapped to templated with defaults you like.
For example https://github.com/antfu-collective/vitesse or https://github.com/preactjs/preset-vite

wooorm · 2024-08-08T11:54:21Z

In my mind, GPLs are for powerless individual coders, and others are for powerful companies, universities or foundations.

I don’t think this understanding is correct; npm being 99% MIT shows that “powerless individual coders” are also using MIT.

But why? No one knows the logic in it, it doesn't make sense. I will do anything for what makes me believe.

You can ask? 😉 What do you want to know?

I thought about that, but it'll be confused for users to find a plugin only support MDX 1.x in MDX 3.x document.

I don’t think I see that? I don’t think so? Why would someone be confused with a note? You can show 2 things in that section?

I’d lean towards adding a note, as it’s something for now, and Parcel will solve it later?

TechQuery · 2024-08-08T12:00:27Z

This plugin is [...] only for individuals.

This concerns me a bit.

I'm sorry, my Speak-to-Text Input Method lost the not, I mean "Not only for individuals"😂

Any build tool can be wrapped to templated with defaults you like.
For example https://github.com/antfu-collective/vitesse or https://github.com/preactjs/preset-vite

If a framework or bundler needs a bunch of scaffold codes to make it good to use, it's not good enough actually.

Zero Configuration design is beyond the presets, because the Web standards are the best presets. Parcel bundles projects based on How we refer assets (build dependency graph with href, src, url(), import, etc.) and What we write (auto install compilers and official plugins with .html, .css, .less, .js, .ts, .tsx, etc.).

If users have some advanced requirements, Parcel's plugin system loads configurations of all the existed tool chains with the original ways (.babelrc, tsconfig.json, etc, as you mentioned before), doesn't like others, such as: Vite's React & Vue plugins have totally different ways to set up Babel configuration with barely no detail document, it makes users to feel exhausted in the migration between frameworks and bundlers...

The Web is simple before, and powerful but complex today. What Parcel does is to make the Web easier again.

ChristianMurphy · 2024-08-08T15:18:42Z

If a framework or bundler needs a bunch of scaffold codes to make it good to use, it's not good enough actually.

Good defaults are important, yes, so is the ability to configure.
I've used Parcel, CRA, and other no config systems.
There comes a point in any sufficiently large project where you need configuration.
Parcel and CRA are not good at configuration/customization.

Parcel bundles projects based on How we refer assets (build dependency graph with href, src, url(), import, etc.) and What we write (auto install compilers and official plugins with .html, .css, .less, .js, .ts, .tsx, etc.).

Right, and so does every other bundler and build tool from the past 2-5 years 🙂
ESBuild, Vite, Rspack, etc all focus on aligning to web standards first and foremost, and have lots of official plugins.

The Web is simple before, and powerful but complex today. What Parcel does is to make the Web easier again.

I'm glad you're excited about web development 🙂
Keep up the passion and energy. 👍

wooorm · 2024-08-08T15:27:48Z

Zero Configuration [...]

There is a place for zero config stuff!

There is also a place for tools, the stuff we make here in unified, that make all the other tools possible. Some of those tools have different needs!

MDX, remark, unified, are configurable. And this is important. If you call your things MDX or unified, they must be configurable as well. If you want a zero-config tool, on top of MDX, you can make that, but it’s not MDX. I think you need a new name.

The Web is simple before, and powerful but complex today. What Parcel does is to make the Web easier again.

I personally don’t think the web has ever been simple. The web is about humans. Not even just humans: human--computer interaction, computer--computer interaction, human--human interaction. That’s always going to be incredibly complex.

remcohaszing · 2024-08-08T15:37:07Z

Re license: I recommend using MIT. It’s free, common, and simple. But you’re free to use whatever license you want. You can always relicense your own projects (but the old license applies to old versions). I don’t think we should block any (L)GPL licensed projects from being listed on the MDX website.

I agree with @wooorm that an MDX integration for a build tool should support MDX options. The current implementation picks an arbritrary list of plugins. Some of these are common, other’s I haven’t even seen before. I think that shows there’s the need for the user to specify their own plugin list.

wooorm · 2024-08-08T15:50:03Z

I agree with @wooorm that an MDX integration for a build tool should support MDX options. The current implementation picks an arbritrary list of plugins. Some of these are common, other’s I haven’t even seen before. I think that shows there’s the need for the user to specify their own plugin list.

Perhaps we should instead document to Parcel users how they can make their own plugin?

I think the core code is:

import {Transformer} from '@parcel/plugin'
import {compile} from '@mdx-js/mdx'

const transform = new Transformer({
  async transform({asset}) {
    const source = await asset.getCode()
    const file = await compile(source)
    asset.type = 'jsx' // Question: this is JS already, should it be `js`?
    asset.setCode(String(file))
    return [asset]
  }
})

export default transform

remcohaszing · 2024-08-08T16:03:02Z

I haven’t used Parcel before, let alone dealt with plugins. I also haven’t looked in depth too much. Don’t they support any configuration options?

Perhaps we should instead document to Parcel users how they can make their own plugin?

Or we could to it like @mdx-js/node-loader: expose a function to make it simple to create your own, and expose one with default configuration.

I think the core code is:

import {Transformer} from '@parcel/plugin'
import {compile} from '@mdx-js/mdx'

const transform = new Transformer({
  async transform({asset}) {
    const source = await asset.getCode()
    const file = await compile(source)
    asset.type = 'jsx' // Question: this is JS already, should it be `js`?
    asset.setCode(String(file))
    return [asset]
  }
})

export default transform

We should pass the file path to compile() if we have access to it. The asset type should indeed match the output type. This means jsx if the {jsx: true} option is passed to compile() or js otherwise. I would also be surprised if Parcel doesn’t have source map support.

TechQuery · 2024-08-08T16:13:01Z

@ChristianMurphy

Parcel and CRA are not good at configuration/customization.

Parcel's plugin system is different than others, but easy to configure & customize.

In the other hand, CRA's configuration/customization is suck.

Parcel bundles projects based on How we refer assets (build dependency graph with href, src, url(), import, etc.) and What we write (auto install compilers and official plugins with .html, .css, .less, .js, .ts, .tsx, etc.).

Right, and so does every other bundler and build tool from the past 2-5 years 🙂 ESBuild, Vite, Rspack, etc all focus on aligning to web standards first and foremost, and have lots of official plugins.

webpack needs <% something %> to inject JS files, others load images, videos, etc by absolute paths from public/, which can't be hinted by your IDE.

But Parcel uses relative paths hinted by IDE, and auto install all compilers & official plugins, which others do not.

TechQuery · 2024-08-08T16:25:18Z

and Parcel will solve it later?

@wooorm Parcel team has few action on MDX upgrading, "later" is undefined for years: parcel-bundler/website#1102

MDX, remark, unified, are configurable. And this is important. If you call your things MDX or unified, they must be configurable as well. If you want a zero-config tool, on top of MDX, you can make that, but it’s not MDX. I think you need a new name.

As I said above:

🚧Because MDX 3 has no official configuration file, so I'm thinking about the configuration schema of my own plugin. I'm glad to have issue or PR submitted for this feature, and hoping a simple design to keep Parcel easy.

When I resolve EasyWebApp/Parcel-transformer-MDX#1, I will rewrite the whole project with TypeScript to replace the quick & dirty version (which is made as the reason of long time waiting for Parcel MDX plugin updating).

so, a "Parcel-MDX plugin" means compile & bundle MDX with Zero Configuration first, and then it will be configurable for customization. I'm designing & implementing the configuration file, no renaming is needed.

ChristianMurphy · 2024-08-08T16:32:39Z

In the other hand, CRA's configuration/customization is [bad].
webpack needs <% something %> to inject JS files, others load images, videos, etc by absolute paths from public/, which can't be hinted by your IDE.

@TechQuery I agree, you're going after a straw-man, I'm not talking about webpack. 🙂

Parcel team has few action on MDX upgrading, "later" is undefined for years

Your code could also shared as a PR to Parcel itself to upgrade the official MDX integration, right?
And if it were updated in the official repo, documentation across GitHub and the internet wouldn't need to be updated.

TechQuery · 2024-08-08T16:39:49Z

webpack needs <% something %> to inject JS files, others load images, videos, etc by absolute paths from public/, which can't be hinted by your IDE.

@TechQuery I agree, you're going after a straw-man, I'm not talking about webpack. 🙂

webpack is also active developing, not too old.
"others" means Vite, etc.

For now, No one latest bundlers implements all Zero Configuration features of Parcel, such as relative paths & auto installation.

Your code could also shared as a PR to Parcel itself to upgrade the official MDX integration, right? And if it were updated in the official repo, documentation across GitHub and the internet wouldn't need to be updated.

@ChristianMurphy I did, look up for the PR link.

TechQuery · 2024-08-08T16:43:32Z

The current implementation picks an arbritrary list of plugins. Some of these are common, other’s I haven’t even seen before.

@remcohaszing All preset MDX plugins come from official "Guides" document, which should be common for most users.

TechQuery · 2024-08-08T16:49:06Z

Perhaps we should instead document to Parcel users how they can make their own plugin?

I think the core code is:

import {Transformer} from '@parcel/plugin'
import {compile} from '@mdx-js/mdx'

const transform = new Transformer({
  async transform({asset}) {
    const source = await asset.getCode()
    const file = await compile(source)
    asset.type = 'jsx' // Question: this is JS already, should it be `js`?
    asset.setCode(String(file))
    return [asset]
  }
})

export default transform

@wooorm My plugin came from parcel-bundler/parcel#7922 (comment), but we shouldn't make Parcel users to write it again & again.

ChristianMurphy · 2024-08-08T17:02:01Z

which should be common for most users.
we shouldn't make Parcel users to write it again & again.

Users have a really wide variety of use cases for MDX.
Vanilla MDX is the most common use case.

If you want to avoid users having to write a custom code for when the do want a plugin.
Support the remark and rehype configuration files so users can add the plugins they want #2523 (comment)

TechQuery · 2024-08-08T19:57:24Z

If you want to avoid users having to write a custom code for when the do want a plugin.
Support the remark and rehype configuration files so users can add the plugins they want #2523 (comment)

@ChristianMurphy @wooorm @remcohaszing Custom Configuration support is released: https://github.com/EasyWebApp/Parcel-transformer-MDX/releases/tag/v0.4.0

TechQuery · 2024-08-09T00:19:12Z

Or we could to it like @mdx-js/node-loader: expose a function to make it simple to create your own, and expose one with default configuration.

@remcohaszing It would be nice if someone upgrades MDX Node.js loader to read configuration from a mdx.config.js file, then EasyWebApp/Parcel-transformer-MDX#1 may be no need to do.

wooorm · 2024-08-09T10:41:26Z

We should pass the file path to compile() if we have access to it. The asset type should indeed match the output type. This means jsx if the {jsx: true} option is passed to compile() or js otherwise. I would also be surprised if Parcel doesn’t have source map support.
— @remcohaszing

all good points!

My plugin came from parcel-bundler/parcel#7922 (comment), but we shouldn't make Parcel users to write it again & again.
— @TechQuery

a) ok, that linked code can be improved
b) I actually do think it’s very useful for developers to learn the core technology they use, so MDX, Parcel, and how to combine them. Instead of inventing a new configuration format. Because again: everyone needs different plugins. Everyone needs that slightly differently. That also means that when Parcel, MDX, or plugins, update, users can update too, they don’t need to wait for you. Or Parcel. I think this is what Grunt and Gulp got wrong.

wooorm · 2024-08-09T10:45:14Z

It would be nice if someone upgrades MDX Node.js loader to read configuration from a mdx.config.js file, then EasyWebApp/Parcel-transformer-MDX#1 may be no need to do.

? I do not understand this issue you created on your repo?

I am not so sure I think mdx.config.js is a good idea?
There is no html.config.js either?

TechQuery · 2024-08-09T16:16:46Z

Instead of inventing a new configuration format. Because again: everyone needs different plugins. Everyone needs that slightly differently. That also means that when Parcel, MDX, or plugins, update, users can update too, they don’t need to wait for you. Or Parcel.

@wooorm I have exposed the whole MDX compile() option object directly in the early morning, no new format is invented, users don't need to wait for upstreams to upgrade.

? I do not understand this issue you created on your repo?

I am not so sure I think mdx.config.js is a good idea?
There is no html.config.js either?

I want to load MDX files directly in Node.js for Server-side Rendering, but @mdx-js/node-loader has no configuration file to load custom options & plugins.

So I need a mdx.config.js just like tsconfig.json (TypeScript language does have a configuration file as a good idea).

wooorm · 2024-10-02T14:56:56Z

Thanks for your patience. I just landed this. Reworded it a bit tho.

docs: update Parcel MDX plugin for MDX 3

f8cd910

Signed-off-by: South Drifted <[email protected]>

vercel bot deployed to Preview August 6, 2024 20:04 View deployment

TechQuery mentioned this pull request Aug 10, 2024

MDX Plugin out of date parcel-bundler/parcel#7934

Closed

wooorm closed this in 6750079 Oct 2, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

docs: update Parcel MDX plugin for MDX 3 #2523

docs: update Parcel MDX plugin for MDX 3 #2523

TechQuery commented Aug 6, 2024

vercel bot commented Aug 6, 2024 •

edited

Loading

codecov-commenter commented Aug 6, 2024

ChristianMurphy commented Aug 6, 2024 •

edited

Loading

TechQuery commented Aug 6, 2024 •

edited

Loading

ChristianMurphy commented Aug 6, 2024

TechQuery commented Aug 6, 2024 •

edited

Loading

wooorm commented Aug 7, 2024 •

edited

Loading

TechQuery commented Aug 7, 2024 •

edited

Loading

ChristianMurphy commented Aug 7, 2024

TechQuery commented Aug 7, 2024 •

edited

Loading

ChristianMurphy commented Aug 7, 2024 •

edited

Loading

wooorm commented Aug 8, 2024

TechQuery commented Aug 8, 2024 •

edited

Loading

ChristianMurphy commented Aug 8, 2024 •

edited

Loading

wooorm commented Aug 8, 2024

remcohaszing commented Aug 8, 2024

wooorm commented Aug 8, 2024

remcohaszing commented Aug 8, 2024

TechQuery commented Aug 8, 2024

TechQuery commented Aug 8, 2024 •

edited

Loading

ChristianMurphy commented Aug 8, 2024

TechQuery commented Aug 8, 2024 •

edited

Loading

TechQuery commented Aug 8, 2024 •

edited

Loading

TechQuery commented Aug 8, 2024

ChristianMurphy commented Aug 8, 2024

TechQuery commented Aug 8, 2024

TechQuery commented Aug 9, 2024

wooorm commented Aug 9, 2024

wooorm commented Aug 9, 2024

TechQuery commented Aug 9, 2024

wooorm commented Oct 2, 2024

docs: update Parcel MDX plugin for MDX 3 #2523

docs: update Parcel MDX plugin for MDX 3 #2523

Conversation

TechQuery commented Aug 6, 2024

Initial checklist

Description of changes

vercel bot commented Aug 6, 2024 • edited Loading

codecov-commenter commented Aug 6, 2024

Codecov Report

ChristianMurphy commented Aug 6, 2024 • edited Loading

TechQuery commented Aug 6, 2024 • edited Loading

ChristianMurphy commented Aug 6, 2024

TechQuery commented Aug 6, 2024 • edited Loading

wooorm commented Aug 7, 2024 • edited Loading

TechQuery commented Aug 7, 2024 • edited Loading

ChristianMurphy commented Aug 7, 2024

TechQuery commented Aug 7, 2024 • edited Loading

ChristianMurphy commented Aug 7, 2024 • edited Loading

wooorm commented Aug 8, 2024

TechQuery commented Aug 8, 2024 • edited Loading

ChristianMurphy commented Aug 8, 2024 • edited Loading

wooorm commented Aug 8, 2024

remcohaszing commented Aug 8, 2024

wooorm commented Aug 8, 2024

remcohaszing commented Aug 8, 2024

TechQuery commented Aug 8, 2024

TechQuery commented Aug 8, 2024 • edited Loading

ChristianMurphy commented Aug 8, 2024

TechQuery commented Aug 8, 2024 • edited Loading

TechQuery commented Aug 8, 2024 • edited Loading

TechQuery commented Aug 8, 2024

ChristianMurphy commented Aug 8, 2024

TechQuery commented Aug 8, 2024

TechQuery commented Aug 9, 2024

wooorm commented Aug 9, 2024

wooorm commented Aug 9, 2024

TechQuery commented Aug 9, 2024

wooorm commented Oct 2, 2024

vercel bot commented Aug 6, 2024 •

edited

Loading

ChristianMurphy commented Aug 6, 2024 •

edited

Loading

TechQuery commented Aug 6, 2024 •

edited

Loading

TechQuery commented Aug 6, 2024 •

edited

Loading

wooorm commented Aug 7, 2024 •

edited

Loading

TechQuery commented Aug 7, 2024 •

edited

Loading

TechQuery commented Aug 7, 2024 •

edited

Loading

ChristianMurphy commented Aug 7, 2024 •

edited

Loading

TechQuery commented Aug 8, 2024 •

edited

Loading

ChristianMurphy commented Aug 8, 2024 •

edited

Loading

TechQuery commented Aug 8, 2024 •

edited

Loading

TechQuery commented Aug 8, 2024 •

edited

Loading

TechQuery commented Aug 8, 2024 •

edited

Loading