Request: give token types and etc to plugins

[mysticatea]

Hello.

Since the installation problem has re-raised due to 7.0.0, I want to revisit #824.

Context:

Issue is eslint/eslint#12119.

espree, the default parser of ESLint, depends on acorn and acorn-jsx.

eslint
└ espree
   ├ acorn 7
   └ acorn-jsx (requires acorn 6 or 7 as a peer dependency)

This expected to work fine because the peer dependency requirement of acorn-jsx satisfies. But, in fact, npm guarantees the peer dependency requirements satisfy, but doesn't guarantee the acorn that espree imports and the acorn that acorn-jsx imports are the same one.

For example, if an end-user installed webpack as well...

webpack
└ acorn 6
eslint
└ espree
   ├ acorn 7
   └ acorn-jsx (requires acorn 6 or 7 as a peer dependency)

Then npm can dedupe those...

webpack
acorn 6 (from webpack)
eslint
espree (from eslint)
└ acorn 7 (pinned in `espree` directory to avoid conflicts)
acorn-jsx (from espree; requires acorn 6 or 7 as a peer dependency)

OK, the peer dependency requirement of the acorn-jsx still satisfies. It's a right installation. But broken. The acorn-jsx imports Webpack's acorn. The espree imports own acorn. So acorn.tokTypes gets different instances.

Here, please mind two acorns are not used at the same time. One is used by Webpack. One is used by ESLint. End users cannot solve this problem. They only can choose to break either ESLint or Webpack or give up the use of new features of those.

There are a lot of packages that depend on acorn. It means that people can depend on acorn indirectly easily, then acorn's plugins are very fragile.

A solution:

I think that the root cause is acorn's plugins cannot get the applied acorn entity. The peer dependencies functionality doesn't guarantee acorn entity is unique because of indirect dependencies.

This PR lets plugins access tokTypes and etc via Parser.acorn.tokTypes and other members. The Parser is the acorn entity that the plugin was applied.

Maybe there are other solutions, but this is an idea. Would you consider to solve this problem?

[marijnh]

@adrianheine @RReverser What do you think? This is a bit kludgey, but seems low-impact, and would allow plugins to migrate to it conditionally (Parser.acorn || require("acorn")).

I'd add Parser to the export object as well, so that it contains the same things as the top-level package.

[mysticatea]

I'm glad if this advanced.

[marijnh]

Right, sorry about that. I've merged this as 90ed904, followed up with 5ef3c9a, and released as 7.1.0

[mysticatea]

Thank you very much!

I have sent acornjs/acorn-jsx#102 to use this feature in acorn-jsx.

[RReverser]

@marijnh Should we backport this to 6.x? Looks like it's still causing issues: acornjs/acorn-jsx#103

[marijnh]

Ugh, what a mess. I guess back-porting would at least make this less painful. I'd be okay with that.

[tlehtimaki]

What would be needed to get the fix backported to 6.x.? I'm facing this issue through react-styleguidist too and would be happy to help. :)

[RReverser]

@mysticatea Do you want to make the backport PR?

[mysticatea]

@RReverser Sorry, I don't think I can, because acorn doesn't have the maintenance branch for 6.x and I don't have permission to create the maintenance branch.

[iansan5653]

@marijnh Could you start a maintenance branch from ac6decb?

[marijnh]

I've set up a 6.x branch that you can create a PR against.

[iansan5653]

@mysticatea Would you still be willing to work on that PR? I can try but I'm not familiar with this library at all so it would take some time.

[tlehtimaki]

I can also help with PR. Although not too familiar with the codebase I will participate to make it reality.

[marijnh]

See #887