mdx
mdx copied to clipboard
Provide recma packages similar to remark
Initial checklist
- [X] I read the support docs
- [X] I read the contributing guide
- [X] I agree to follow the code of conduct
- [X] I searched issues and couldn’t find anything (or linked relevant results below)
Problem
I’ve just created a recma plugin (to be released soon!). Although this package is intended for use with MDX, it just uses the estree. Not all cases that should be, can be covered using MDX. Plugins may inject estree nodes that can’t usually be defined writing MDX syntax (I.e. unexported top-level variable declarations).
Solution
It would be nice if recma
can be published as a set of individual packages, just like remark
. So there would be recma
, recma-parse
, and recma-stringify
(already part of @mdx-js/mdx
).
I could publish this myself, but I think it’s good to keep this as part of the unified collective.
Alternatives
N/A
I’ve been holding off because it would mean adding another org. 😅 What plugin are you making?
I’ve been holding off because it would mean adding another org. :sweat_smile:
I don’t need it per se, but it would make the tests nicer.
What plugin are you making?
A plugin which makes all global variables available in pages/_app.js
in Next.js projects by injecting getStaticProps
. :smile:
This is really useful to use for example frontmatter data or the page title for the active page in pages/_app.js
.
Ah nice! We could start with recma-stringify
, here, versioned on its own just like remark-mdx
.
We could add recma-parse
here too, though it isn’t used here.
Though the utility versions of these can definitely live in syntax-tree
, already, and most of the logic would be in them instead of in the wrapper plugins.
It might be nice to extract the JSX parsing and stringifying into recma-jsx
in a similar way language extensions work for remark (such as remark-frontmatter
). This could also open up the ability to add more syntax extensions.
It appears there’s already a GitHub profile named recma. Maybe the recma ecosystem should be kept within the mdx-js organization then?
Also I’d like to emphasize I don’t need it, but I think this would be nice to have. I believe this might encourage people to start making third party recma plugins. The concept of recma currently feels a bit more abstract than remark or rehype, because the ecosystem isn’t there yet.
I’m not exactly sure where it was, but ± a year ago there was also a discussion of forking astring
(the serializer), because it’s not perfect and not very actively maintained. I’ve also attempted to upstream the JSX handling, but my PR is stuck.
Us maintaining an org, and indeed having recma-jsx
or so, could also help with types. Currently estree
is not extendible, and there are differences between estree/astring/acorn types. Controlling it all likely improves that interoperability.
there’s already a GitHub profile named recma
@recmajs
is available, and that’s the same as @remarkjs
/@rehypjes
/etc!
I believe this might encourage people to start making third party recma plugins
Yeah. Though I also believe that that need for plugins, needs to be there for to warrant the time spent on making an ecosystem!
As the author of the second only Recma plugin I've ever seen, I second this. I'm also using @remcohaszing's plugin, and it would have been quite pleasant to find both plugins I needed for my use case with just a cursory search through the Unified family of libraries.
+1, i'd be interested for this as well.
My need is a basic access to recma-stringify
in order to build proper output for a webpack/rollup loader (currently using export default ${JSON.parse(code)}
which works ok tho so it's not critical.)
The utilities are already there btw: https://github.com/syntax-tree/esast-util-from-js, https://github.com/syntax-tree/estree-util-to-js. Making an org and these wrappers is the plan, but I’m rather busy updating the entire ecosystem currently!