Turf: A build that uses ES6 modules

[gajus]

With several module bundlers (webpack 2 and rollup) now supporting tree shaking:

Tree shaking?
Normally if you require a module, you import the whole thing. ES2015 lets you just import the bits you need, without mucking around with custom builds. It's a revolution in how we use libraries in JavaScript, and it's happening right now.

It would be amazing if there was a turf build using import. This would drastically reduce the build size (which is now nearing ~500kb with just a handful of features being used).

[tmcw]

This is pretty possible; we'd add a jsnext:main that's basically https://github.com/Turfjs/turf/blob/master/index.js but with export instead of module.exports.

Solving the long-term size problem is almost all about eliminating JSTS https://github.com/Turfjs/turf/issues/88

[tmcw]

Unfortunately, after some digging into ES6 modules, this ends up being quite difficult to implement. Happy to accept a PR implementing this change, but closing as a priority for the existing maintainers because it's a doozy of a lift.

[gajus]

Unfortunately, after some digging into ES6 modules, this ends up being quite difficult to implement.

Can you document the difficulties implementing ES6 module?

• Next lodash (v5) will support ES6 modules natively. https://github.com/lodash/lodash/wiki/Roadmap
• webpack 2 already supports ES6 modules.
• ES6 module support has been added to Edge.

It appears counterproductive to close this issue now.

[tmcw]

Sorry - I'm trying to slim down Turf's issues to those that are actionable immediately. Right now we have quite a few issues that are very long-term and almost no core maintainer time (i led the vast majority of turf 3 solo), so focusing is a priority. Closing issues does not mean that it's deprioritizing the request or saying that nobody should do it: I want PRs to be the primary documentation of work rather than issues, and I explicitly will say that a PR is accepted if I close an issue.

Problems here are:

• ES6 module support in Node.js is still very far away and no other JavaScript runtime - no browser - supports ES6 modules. This means that tests for es6-turf will require a transpilation step, always, which is a total bummer and a big change in our infrastructure's simplicity
• Top-level es6 modules with lower-down commonjs doesn't really work; this is what I tried to do with simple-statistics and it turned out that if you really _want_ tree-shaking you need more than a top-level file.

Lodash is able to support ES6 modules mainly because it's a very... meta project. All of the lodash code is generated dynamically for every single build, and it's totally different than any other JavaScript project in the whole ecosystem. Going the lodash way would be awesome, but would be a massive change.

Sorry again that closing the issue seemed counterproductive: this is not a "no for everyone", it's me trying to define the scope given my estimation of the work's time requirement versus its benefit and other features, and keeping Turf's scope to a level that's accomplishable without further severe burnout.

[gajus]

Sorry again that closing the issue seemed counterproductive: this is not a "no for everyone",

Maybe adding labels would be a good alternative? e.g. priority:1-10, difficulty:1-10, etc.

[gajus]

From my experience maintaining (albeit smaller) open-source projects, closed issues almost inevitably get lost forever.

[tmcw]

I'm not really convinced on the value of issues anymore: difficult open issues on repositories have a negligible chance of being picked up by passers-by and getting fixed. Is a two-year old issue more useful than no issue at all? Issues that are difficult end up just getting +1ed or "is this fixed" for the duration of time before they either get locked, a maintainer implements them, or they become required in some other way, like if the functionality becomes essential to someone's project or company, and in that case they're going to implement the feature issue or not.

I think issues work well for small changes or bug reports, but for large features they're often counterproductive or a productivity placebo.