Expose Acorn allowImportExportEverywhere option

Meteor version 1.3.3.1, just released, allows imports to be made from within conditionals and nested scopes. This was a welcome change.

Regrettably, it causes an actual parsing error in ESLint.

 272:7  error  Parsing error: 'import' and 'export' may only appear at the top level

I dissected enough of your code to find that Acorn has an option that adds the support we in the Meteor community need - the allowImportExportEverywhere option. I added code in my local copy of Espree to accept allowImportExportEverywhere as an ecmaFeature and pass it through to Acorn. It took all of three lines and accomplished exactly what I’d hoped.

In espree.js:

        // apply parsing flags after sourceType to allow overriding
        if (options.ecmaFeatures && typeof options.ecmaFeatures === "object") {
            extra.ecmaFeatures = options.ecmaFeatures;
            impliedStrict = extra.ecmaFeatures.impliedStrict;
            extra.ecmaFeatures.impliedStrict = typeof impliedStrict === "boolean" && impliedStrict;
            if (options.ecmaFeatures.globalReturn) {
                acornOptions.allowReturnOutsideFunction = true;
            }
// begin new code
            if (options.ecmaFeatures.allowImportExportEverywhere) {
                acornOptions.allowImportExportEverywhere = true;
            }
// end new code
        }

In addition, it looks as though changing the current “meteor” environment implementation as follows makes it default that way for Meteor users.

In environments.js:

    meteor: {
        globals: globals.meteor,
        parserOptions: {
          ecmaFeatures: {
            allowImportExportEverywhere: true
          }
        }
    },

I’ve read the notes at the bottom of your READMEs in both ESLint and Espree discouraging “experimental features”. This one isn’t experimental within the Meteor community now, it’s production. And it promises to lead to exciting new capabilities in the future such as automatic code splitting. Furthermore, the NPM “reify” module that implements it is available to the whole NPM community, and Meteor itself will soon be moving to NPM. So it will spread beyond the Meteor community.

Please consider the above changes.

Also, I’d be happy to create PRs though I believe the above is basically it.

[rhettlivingston]

I might be wrong (@hzoo can correct me), but isn’t it possible to create a Babel plugin to support your extra syntax? If so, I’d think that babel-eslint could work with it.

Thank you very much for this suggestion. I will dig into babel-eslint again and see if such a thing is possible. I know that Ben Newman plans a Babel plugin that includes his “reify” package that transpiles nested imports and exports. But for this purpose, I don’t need the actual implementation that transpiles it all, I just need the parser to accept it. So, if a babel plugin can be specified without forking things and can turn on the flag for parsing, that would be a start.

Acorn only added the flag because Babel used to allow it.

Purely in the interest of history (which I find fun), the issue records in Acorn indicate that they added the flag when they “corrected” their parser to not support it on December 8, 2014. Babylon, the parser used by babel-eslint, states in their credits “Heavily based on acorn and acorn-jsx, thanks to the awesome work of @RReverser and @marijnh.” I went back to the Babylon repository view of December 7, 2014 and found that their README at that time was still titled “Acorn” in blazing letters at the top and their main parser was in “acorn.js”. So Babylon, which began its life based on acorn before that date in history, inherited its “problem” with nested imports from acorn and “fixed” them after Acorn did by adopting Acorn’s fix.

[nzakas]

Now supported via babel-eslint (thanks @hzoo!), so closing.