Release - 2.0.0-alpha

[nivida]

Description

This is the release of the new architecture with the old API layer.
Closer details will be explained in the coming release announcement.

Compare View

v1.0.0-beta.55 -> v2.0.0-alpha

Type of change

• Release

Checklist:

• I have selected the correct base branch.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no warnings.
• I have updated or added types for all modules I've changed
• Any dependent changes have been merged and published in downstream modules.
• I ran npm run lint in the root folder with success and pushed the changes.
• I ran npm run test in the root folder with success and extended the tests to cover all changes.
• I ran npm run build in the root folder and tested it in the browser and with node.
• I ran npm run dtslint in the root folder and tested that all my types are correct
• I have tested my code on an ethereum test network.

[coveralls]

Coverage decreased (-0.08%) to 95.664% when pulling a09d2cc on release/2.0-alpha into 8ed2fbc on 2.x.

[michaelsbradleyjr]

With node v8.x reaching EOL by the end of this year and v12.x becoming LTS in October of this year, have you considered a breaking change whereby web3 2.x would drop support for node v8.x by switching over to the built-in scrypt that's available in node v10.x and v12.x? Since 2.x is a major version release, and since there are other breaking changes, it seems justifiable.

[emizzle]

Agreed with the above - built in scrypt support is a HUGE win for any app/package that uses web3 as a dependency. It will significantly reduce the time needed to add/remove other deps, and also reduce the pre-install requirements for apps that depend on web3 (ie gcc and python@2.x)

[michaelsbradleyjr]

Worst case scenario, I guess, is that node v12.x compatibility can't land as a 2.x.0 feature release because it turns out to be too difficult or impossible to have a well-performing scrypt solution that works for node v8.x – v12.x (inclusive) and therefore v12.x compatibility has to wait until web3 v3.x, i.e. another major version release wherein dropping node v8.x support is one of the breaking changes.

[michaelsbradleyjr]

Hopefully PR #2937 can be considered prior to release.

[nivida]

With node v8.x reaching EOL by the end of this year and v12.x becoming LTS in October of this year, have you considered a breaking change whereby web3 2.x would drop support for node v8.x by switching over to the built-in scrypt that's available in node v10.x and v12.x? Since 2.x is a major version release, and since there are other breaking changes, it seems justifiable.

Yes, I've considered it. It's planned to support v12 with the 2.0 stable release and to remove un-supported versions like v8 of nodejs. Version 2.0 does provide the same API as 1.0 just with internal changes and some smaller changes on the Contract object of web3.js. I will still expose the big Web3 object in 2.0 but will add the new API layer as well. This means the old modules will still exist in 2.0 for providing backward compatibility for these projects who already have switched to the new architecture of web3.js and in addition will I expose the new really tree-shakable and more functional API. A first draft of the new planned API can be seen in the coming blog post.

[michaelsbradleyjr]

Heads up:

I've been working on #2938, which is an adaptation of #2937 (which you already merged into this PR's branch) to web3 1.0. I've found that node's built-in scrypt has problems with 1.0's static tests.

For one, it can't handle a large "n" though it's definitely aggravated by a "p" > 1. Also, even after decreasing "n" significantly, there was a case of it not being able to successfully decrypt, as if the password was wrong. The latter problem may be owing to mistakes I made in the REPL, etc. Or it may be related to #2905 (comment). These behavioral differences between the scrypt package and Node's built-in crypto.scrypt would certainly affect web3 2.0.0-alpha as well.

I plan to revisit this over the weekend as at the moment I'm tired and may be introducing user error into the mix. Worst case scenario, I guess bcd1d88 would end up reverted on this PR's branch.