Add option to specify my own acorn

Acorn and acorn-jsx are hardcoded in espree which makes it hard to extend espree for other syntax flavors.

// reference code from espree
var acornJSX = require("acorn-jsx/inject"),
var rawAcorn = require("acorn");
var acorn = acornJSX(rawAcorn);

// following down the code
        if (extra.ecmaFeatures.jsx) {
            // Should process jsx plugin before espree plugin.
            acornOptions.plugins = {
                jsx: true,
                espree: true
            };
        }

I wrote my own acorn extension, and I would like to feed it to espree in my eslint plugin.

The way I do it now is monkey patch api.verify in eslint with the following code:

const proxyquire = require('proxyquire');

let espreePath = Object.keys(requireCache).find(key => key.endsWith(path.join('espree', 'espree.js')))
espreePath = espreePath ? espreePath : 'espree'
let acornPath = Object.keys(requireCache).find(key => key.endsWith(path.join('dist', 'acorn.js')))
acornPath = acornPath ? acornPath : 'acorn'

const acorn = require(acornPath)
const acornVFEL = require('@salesforce/acorn-visualforce/dist/inject')(acorn, true)
const espree = proxyquire(espreePath, { acorn: acornVFEL })

Which is a) ugly, b) prone to errors.

The problem with this approach is that acorn-jsx is injected later overriding my overrides to acorn. Ideally, my plugin should be injected after acorn-jsx, but there is no way I can do it currently.

Is it possible to add an option to espree to specify my own acorn package in a fashion that acorn-jsx does? It should be a very simple addition, something like var acorn = options.acorn || require("acorn-jsx")

[not-an-aardvark]

Thanks for explaining.

It would require some effort to rewrite them to make it “injectable”, but I’m willing to do this, as long as I’ll have confidence that the maintainers are onboard with this change.

Please don’t do this yet – I was just throwing an idea out there, and I’m not sure it’s the right choice 😃

[nzakas]

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to be implemented after 90 days tend to never be implemented, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.