leafac
Currently babel-plugin-macros requires macros to be defined in files that match `/[./]macro(\.c?js)?$/`. What if that was `/[./]macro(\.[cm]?js)?$/`?
#188 · open · 13 comments
Currently babel-plugin-macros requires macros to be defined in files that match `/[./]macro(\.c?js)?$/`. What if that was `/[./]macro(\.[cm]?js)?$/`?
`.mjs` files can't be imported without an `await`, which is a problem since babel visitors are sync.
I'm working on a project called `cst-tokens`, a native-JS virtual machine for syntax and semantics that is heavily inspired by the babel and eslint internals but uses a generator-based visitor architecture. I expect it to be able to solve problems like this.
@conartist6 Thank you for the information. Would it be feasible for babel-plugin-macros itself to work around this with [the trick that it recommends to macro authors](https://github.com/kentcdodds/babel-plugin-macros/blob/8fc6383ef04f628d0b799a9b281c5fc0693b25ac/other/docs/author.md#async-logic)?
I don't think so? Kind of the point of a macro is that it exposes babel's APIs, but those objects and functions wouldn't be available in a child process.
> @conartist6 > > I don't think so? Kind of the point of a macro is that it exposes babel's APIs, but those objects and functions wouldn't be available in a child process. Hmmm, yeah, right. I suppose it could still work by serializing the whole AST to JSON. But that sounds very clunky. It’s too bad, really, given that the ecosystem is moving from CommonJS to ESM… 🤷 Thank you again for the information. I’m closing this issue for now. If anything changes or someone comes up with a better idea we can reopen it.
Sounds good. To reiterate: I am fairly confident that I have the solution to this and other critical problems with babel. I am working full time on developing that solution.
Want to breathe a new life into this issue. https://github.com/babel/babel/issues/16860
Update, async pre/post is merged to the babel-core and available from `7.26.0` i'm going to prepare PoC with ESM macros support
What will it look like when plugin-macros is used with an older version of Babel that lacks that feature?
Until user will not use any mjs macro it will work, so no breaking changes. If user tries to use such macro and use older babel version, babel itself will throw a useful error message about the need to update to the latest version.
Reopening the issue since we have a way forward now.
I actually played with that a little bit and unfortunately i could not process without modernizing the tools in this repo. The old tools simply not work with ESM and brings a lot of complications. I could do first modernizing the tooling in the separate PRs, but want to know what you are thinking about that first. Also implement this support for the syntax ESM syntax is quite easy, since it's static and could be only in the Program Statements, but for the `require()` macro support it's a bit more tricky because they could be anywhere in the AST. @conartist6 feel free to contact me directly in discord or email, so we can discuss a plan to move it forward.
Ah yeah. I'm already so heavily invested in making the next generation of tools that at that point I'd rather spend my time on that.