question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Conversion to ES6 should have resulted in a major version change

See original GitHub issue

Due to ES6 conversion, this module no longer works in Node.js environments < 4. As a result, while electron is perfectly usable in earlier environments, downloading electron no longer works. This is causing builds to fail during the npm install process.

The workaround here, in order to support earlier environments, would be to either a) revert back to ES5 or b) use babel or some other transpiler to transpile the ES6 code to ES5 pre-publish.

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Comments:5 (2 by maintainers)

github_iconTop GitHub Comments

1reaction
maleptcommented, Sep 11, 2016

Personally, I’d be more inclined to yank 2.2.0 and publish 3.0.0.

0reactions
kgrytecommented, Sep 11, 2016

@malept

Re: b. Fair enough. Although nothing about checksum support demands ES2015 features and thus necessitates breaking changes.

Re: a) and electron-userland/electron-prebuilt#189. I fail to see why dropping support for prior Node.js versions is a good thing. 0.12 is still an officially supported version through the end of the year. 0.10 (officially supported until October) still has considerable use in enterprise deployments. In particular, electron should not be forced to undergo a breaking change simply to accommodate this module’s decision to only support ES2015 environments.

Re: c. While I can sympathize with the desire to clean-up and modernize a code base, ultimately that needs to be balanced with a code base’s use in the broader context. Here, that context is electron, which should be capable of being installed alongside any version of Node.js >=0.10. And I’d argue that electron and its supported install environments should dictate the supported install environments of associated tooling, not the other way around. So, in this case, the decision to clean-up should consider this constraint and view using sthg like babel as part of the cost of modernization.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Convert to ECMAScript modules for tree shaking support #389
We are considering it for the next major version. typescript or not, it's not a breaking change, so this could be included in...
Read more >
ECMAScript 6 sets: union, intersection, difference - 2ality
Convert one or both sets to arrays. Perform the operation. Convert the result back to a set. As explained in, the spread operator...
Read more >
How to transpile ES modules with webpack and Node.js
Learn how webpack interacts with and supports ES modules in this deep dive tutorial on transpilation in Node.js.
Read more >
Migrating to v2.0.0 - ESLint - Pluggable JavaScript Linter
ESLint v2.0.0 is the second major version release. As a result, there are some significant changes between how ESLint worked during its life...
Read more >
How can I compare software version number using JavaScript ...
Important note: This code uses Array.map and Array.every , which means that it will not run in IE versions earlier than 9. If...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found