Esm eslint

[brettz9]

Builds on #33.

• Breaking change: Enhancement: Add native ESM distribution, with exports property in package.json
• Refactoring: Add Rollup/Babel/Terser
• Build: Have generator file produce consumable source files directly rather than logging to console
• Linting: Switch from JSHint to ESLint (using rules, e.g., indent and prefer-const, in place on other estools project)
• Testing: Convert coffeescript test files to ES6
• Testing: Add nyc
• Testing: Check unmatched high surrogates and full coverage for AST
  expressions (further true isExpression and isStatement's and
  false isProblematicIfStatement), bringing to 100% coverage
• Travis: Drop previous versions for 12, 14, 16

[ljharb]

this is a breaking change, since the dir name changed.

[brettz9]

Sure. I thought I would put it out there as such (in case other breaking changes were to be agreed upon anyways, such as use of exports as you mention). I can switch back to lib if the project maintainers wish, especially if there are no other breaking changes like exports being introduced, as would especially justify a switch to the clearer use of dist and which could, going forward, make it easier to avoid breaking changes (except to those using explicit node_modules paths, though even the docs themselves don't seem to consider that a semver violation).

[ljharb]

this isn’t a standard thing; ESM uses .mjs and the “exports” field (adding that field is also a breaking change)

[brettz9]

Yes, it is not standard but it is widely used and supported by bundlers like Webpack and Rollup.

As far as adding that field being a breaking change (if you mean module instead of exports), I'm not sure that would be the case here. It can be a breaking change when the module is pointing to untranspiled source.

There are advantages to pointing to untranspiled source, such as potentially minimizing package size and avoiding baking in dependencies, but that is not the case here where I am pointing to the rolled up (and Babelified) dist file.

And for those who might argue for changing to point to untranspiled source, on the one hand, this has disadvantages, besides of being a breaking change, of putting the work of building (and understanding of how to do so) on the consumer). Still, some might desire such a build, as with estools/esquery#104 just filed against esquery, and for such use cases, it may indeed be better to add the breaking change to untranspiled source since it would bring the above-mentioned benefits (and those wishing to use a separate prebuilt distribution file could point to that file directly, whether the path to it is changed to be modulated by exports or not).

I would be happy adding the "mjs" extension to give proper Node ESM support (though we might clarify that it is not ESM that necessarily uses the extension, but Node which uses it), or a type change and/or the addition of exports (which would itself be a breaking change of sorts).

[ljharb]

Adding module isn't a breaking change because nothing should be using nonstandard fields; adding exports is what I was referring to.

[brettz9]

As far as the statement that "nothing should be using nonstandard fields", this is a good goal when equivalent ones are available, but otherwise I don't see that as a universally agreed upon goal. :)

module is not necessarily for Node only, nor is need for it removed with standard ESM implementations (it is an entry point for bundling). One might even argue it is a standard relative to the tools that have adopted its usage. And as far as its use relative to Node, Node has even made explicit it not opposing non-Node uses within its package.json, e.g.: re: exports custom conditions:

Other conditions such as "browser", "electron", "deno", "react-native", etc. are ignored by Node.js but may be used by other runtimes or tools. Further restrictions, definitions or guidance on condition names may be provided in the future.

https://nodejs.org/api/esm.html#esm_conditional_exports

But again, I'm happy to add proper Node support for non-bundled usage as well (if there is agreement on using mjs over type: module).

(As an aside re: standards, we might consider that Node itself drifted away from the then CommonJS standard it had been following.)

[ljharb]

Rather than using rollup, why not use “exports” which prevents require or import of files you don’t want to be in your public api?

[brettz9]

As you may have been indicating yourself, exports is itself a breaking change itself of sorts, given how it may restrict access to formerly accessible module-based paths.

I like adding Rollup as it offers the ability to provide a version which can work in ESM-supporting browsers without build steps. I'd personally be cool adding exports in addition, having the potential to minimize future breaking changes.

[brettz9]

Btw, though it doesn't look like it should be an issue in this repo, and shouldn't be too much of a big deal in the other estools repos (except impacting instanceof checks for exported classes), there is a potential concern for the "Dual Package Hazard" in estraverse (which has non-isolated state in its configuration of Syntax, VisitorKeys, and VisitorOption) and escodegen (which has non-isolated state for its options).

This might call for its own breaking change to isolate state (preferably the ESM-based approach indicated at https://nodejs.org/api/esm.html#esm_approach_2_isolate_state ).

[ljharb]

"work in ESM-supporting browsers without build steps" isn't a universally agreed upon goal, nor one that's pleasant to support in node packages :-/ i'll step back and leave it to maintainers decide if that's something that they think is important.

[brettz9]

I can also step back to see what the maintainers say about the inclusion of a prebuilt ESM build for browsers, but I will point out:

1. esquery already accepted a prebuilt ESM build for browsers.
2. Another estools project, escodegen, already has a browser build, so these are apparently not intended as exclusively Node packages.

[brettz9]

I went ahead and added the native ESM support with exports.

If this organization is dead the new releases, I would appreciate a heads up, as I've already started making forks of other projects, not having heard back. But I'm happy to submit my test improvements, etc. if someone still wishes to review and maintain.