Closed marijnh closed 5 years ago
(To test, you'll have to symlink in a build of the current Acorn master branch)
6.0.0 has been released now. If you want me to add something like a Bublé pass, let me know!
Sorry, last few days have been busy. I'll review early next week.
👋
Generally seems good to me, thanks for your work!
Aside from ES6 (which doesn't worry me much at this point tbh, if someone needs to, they can transpile) one thing that comes to mind is removal of index.js
. On one hand, this makes consumer think about composing all the plugins together which is a good thing generally, but on another I don't think there is much harm in continuing providing a prepared instance of Acorn with JSX support? Not sure yet.
Ok, I suppose it's fine...
Published as 5.0.0.
Thanks!
We could have provided an extended Parser
instance in the public API, to remove the need for people to require
two packages. But I kind of like that Acorn can be a peer-dependency this way, which removes issues around npm or yarn installing/loading multiple versions of Acorn.
This is a proof-of-concept porting the plugin to the (unreleased, proposed) plugin API for Acorn 6. I'd like to get your opinion on whether this is a reasonable way forward (both for the Acorn API and for this plugin.) Some issues that might be contentious are:
I ported the code to ES6 to have access to
class
andsuper
syntax, which the new API more or less relies on. We could add a Bublé or Babel build step if targeting old runtimes is important.I removed the split between index.js and inject.js, since plugins are now first-class values are the old default export style no longer makes much sense.
I think that for a plugin like this, listing the host package as both a devDependency and a peerDependency is the proper thing to do, and it seems to work in typical circumstances (stand-along dev on the package, and use as a dependency) but the docs for package.json fields are pretty awful, so who knows what problems this might cause.
The structure of the code itself is pretty much identical to how it used to be, except that I'm not mutating the objects in the main library, but keeping token types and contexts local, and putting new methods in the mixin class.