Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESM CJS builds #5904

Merged
merged 23 commits into from
Mar 28, 2023
Merged

ESM CJS builds #5904

merged 23 commits into from
Mar 28, 2023

Conversation

jdevcs
Copy link
Contributor

@jdevcs jdevcs commented Mar 8, 2023

Description

#5241

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist for 1.x:

  • 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 new warnings.
  • Any dependent changes have been merged and published in downstream modules.
  • I ran npm run dtslint with success and extended the tests and types if necessary.
  • I ran npm run test:cov and my test cases cover all the lines and branches of the added code.
  • I ran npm run build with success.
  • I have tested the built dist/web3.min.js in a browser.
  • I have tested my code on the live network.
  • I have checked the Deploy Preview and it looks correct.
  • I have updated the CHANGELOG.md file in the root folder.

Checklist for 4.x:

  • I have selected the correct 4.x base branch.
  • Within the description, the feature or issue is discussed in detail or an issue is linked.
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas.
  • I have added any required tests for the changes I made
  • I have made corresponding changes to the documentation
  • Any dependent changes have been merged and published in downstream modules.
  • I ran yarn successfully
  • I ran yarn lint successfully
  • I ran yarn build:web successfully
  • I ran yarn test:unit successfully
  • I ran yarn test:integration successfully
  • I ran compile:contracts successfully
  • I have tested my code.
  • I have updated the corresponding CHANGELOG.md file in the packages I have edited.

@jdevcs jdevcs added the 4.x 4.0 related label Mar 8, 2023
@jdevcs jdevcs changed the title Junaid/5241 esm cjs builds [Draft] ESM CJS builds Mar 8, 2023
@codecov
Copy link

codecov bot commented Mar 8, 2023

Codecov Report

Merging #5904 (3573c8a) into 4.x (dd33e17) will increase coverage by 0.01%.
The diff coverage is 100.00%.

Additional details and impacted files
@@            Coverage Diff             @@
##              4.x    #5904      +/-   ##
==========================================
+ Coverage   82.14%   82.15%   +0.01%     
==========================================
  Files         137      137              
  Lines        5981     5985       +4     
  Branches     1572     1576       +4     
==========================================
+ Hits         4913     4917       +4     
  Misses       1068     1068              
Flag Coverage Δ
UnitTests 82.15% <100.00%> (+0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components Coverage Δ
web3 ∅ <ø> (∅)
web3-core ∅ <ø> (∅)
web3-errors ∅ <ø> (∅)
web3-eth ∅ <ø> (∅)
web3-eth-abi ∅ <ø> (∅)
web3-eth-accounts ∅ <ø> (∅)
web3-eth-contract ∅ <ø> (∅)
web3-eth-ens ∅ <ø> (∅)
web3-eth-iban ∅ <ø> (∅)
web3-eth-personal ∅ <ø> (∅)
web3-net ∅ <ø> (∅)
web3-providers-http ∅ <ø> (∅)
web3-providers-ipc ∅ <ø> (∅)
web3-providers-ws ∅ <ø> (∅)
web3-rpc-methods ∅ <ø> (∅)
web3-utils ∅ <ø> (∅)
web3-validator ∅ <ø> (∅)

@github-actions
Copy link

github-actions bot commented Mar 9, 2023

Bundle Stats

Hey there, this message comes from a github action that helps you and reviewers to understand how these changes affect the size of this project's bundle.

As this PR is updated, I'll keep you updated on how the bundle size is impacted.

Total

Asset Old size New size Diff Diff %
Total 1.06 MB 1.06 MB -1.34 KB -0.12%
View detailed bundle breakdown

Added

Asset Old size New size Diff Diff %
../lib/commonjs/accounts.d.ts 0 3.39 KB 3.39 KB -
../lib/commonjs/types.d.ts 0 1.64 KB 1.64 KB -
../lib/commonjs/abi.d.ts 0 966 bytes 966 bytes -
../lib/commonjs/index.d.ts 0 864 bytes 864 bytes -
../lib/commonjs/web3.d.ts 0 808 bytes 808 bytes -
../lib/commonjs/eth.exports.d.ts 0 280 bytes 280 bytes -
../lib/commonjs/providers.exports.d.ts 0 191 bytes 191 bytes -
../lib/commonjs/version.d.ts 0 60 bytes 60 bytes -

Removed

Asset Old size New size Diff Diff %
../lib/accounts.d.ts 3.42 KB 0 -3.42 KB -100.00%
../lib/types.d.ts 1.68 KB 0 -1.68 KB -100.00%
../lib/types.d.ts.map 1.51 KB 0 -1.51 KB -100.00%
../lib/abi.d.ts 999 bytes 0 -999 bytes -100.00%
../lib/index.d.ts.map 919 bytes 0 -919 bytes -100.00%
../lib/index.d.ts 899 bytes 0 -899 bytes -100.00%
../lib/web3.d.ts 842 bytes 0 -842 bytes -100.00%
../lib/web3.d.ts.map 694 bytes 0 -694 bytes -100.00%
../lib/accounts.d.ts.map 528 bytes 0 -528 bytes -100.00%
../lib/eth.exports.d.ts.map 358 bytes 0 -358 bytes -100.00%
../lib/eth.exports.d.ts 321 bytes 0 -321 bytes -100.00%
../lib/providers.exports.d.ts.map 292 bytes 0 -292 bytes -100.00%
../lib/providers.exports.d.ts 238 bytes 0 -238 bytes -100.00%
../lib/version.d.ts.map 140 bytes 0 -140 bytes -100.00%
../lib/abi.d.ts.map 124 bytes 0 -124 bytes -100.00%
../lib/version.d.ts 97 bytes 0 -97 bytes -100.00%

Bigger

No assets were bigger

Smaller

No assets were smaller

Unchanged

Asset Old size New size Diff Diff %
web3.min.js 1.05 MB 1.05 MB 3.45 KB 0.32%

@cloudflare-workers-and-pages
Copy link

cloudflare-workers-and-pages bot commented Mar 13, 2023

Deploying with  Cloudflare Pages  Cloudflare Pages

Latest commit: 3573c8a
Status: ✅  Deploy successful!
Preview URL: https://fb4a71c4.web3-js-docs.pages.dev
Branch Preview URL: https://junaid-5241esmcjsbuilds.web3-js-docs.pages.dev

View logs

@jdevcs
Copy link
Contributor Author

jdevcs commented Mar 15, 2023

node users will need to use --experimental-specifier-resolution=node if they want to use our ESM builds, as we are not importing files in our packages with file extension. (This is for ESM node apps, using our ESM build )

@@ -15,7 +15,8 @@ You should have received a copy of the GNU Lesser General Public License
along with web3.js. If not, see <http://www.gnu.org/licenses/>.
*/

import { TransactionFactory, TypedTransaction } from '@ethereumjs/tx';
import { TypedTransaction } from '@ethereumjs/tx';
import defaultImport, * as fullImport from '@ethereumjs/tx';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While local testing in ESM app and importing web3 ESM build there was problem in importing TransactionFactory from @ethereumjs/tx, reason with ESM @ethereumjs/tx is not exposing named export but exporting under default but with CJS @ethereumjs/tx is exporting it with named export. Following fix is applied in eth and accounts package and it imports both default and all ( named + default ) making sure that we will not miss TransactionFactory in either esm or cjs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This export problem is fixed in @ethereumjs/tx in 4.x and we can upgrade to that in our 4.x after reviewing breaking changes in another PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm maybe you should try again, now that types are first in export. Maybe also publish repro repo^^

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It isnt issue in web3 exporting, but in ethereumjs/tx lib. I tested in another proj as well.

@jdevcs jdevcs marked this pull request as ready for review March 21, 2023 21:10
@jdevcs jdevcs requested a review from a team as a code owner March 21, 2023 21:10
@jdevcs jdevcs changed the title [Draft] ESM CJS builds ESM CJS builds Mar 21, 2023
@@ -3,8 +3,6 @@
"resolveJsonModule": true,
"forceConsistentCasingInFileNames": true,
"target": "es2016",
"module": "commonjs",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now we have base config for building in root with common configuration items.

@@ -0,0 +1,9 @@
{
"extends": "../../tsconfig.base.json",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

each package has three configs for building CommonJS, ESM and type defs, these are extending from base config in root

"build": "tsc --build",
"build": "yarn build:cjs && yarn build:esm && yarn build:types",
"build:cjs": "tsc --build tsconfig.cjs.json && echo '{\"type\": \"commonjs\"}' > ./lib/commonjs/package.json",
"build:esm": "tsc --build tsconfig.esm.json && echo '{\"type\": \"module\"}' > ./lib/esm/package.json",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was explicitly required to have package json in build dir ( lib ) to explicitly override module type for correctly loading ESM when required so I am generating here a package json in lib

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need that for cjs dir

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By default its not required, but I kept it to always override any higher level package config ( in client app) for surely giving error in case if any module type is loaded / referred by mistake.
Do you think it will cause any issue in client side if we keep this explicit overriding file?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No idea tbh

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jdevcs Maybe it would be better to use nodejs script for this. Afaik this excludes developers on windows to build library^^

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for creating package.json? I think echo is also avalible in win

"build": "tsc --build",
"build": "yarn build:cjs && yarn build:esm && yarn build:types",
"build:cjs": "tsc --build tsconfig.cjs.json && echo '{\"type\": \"commonjs\"}' > ./lib/commonjs/package.json",
"build:esm": "tsc --build tsconfig.esm.json && echo '{\"type\": \"module\"}' > ./lib/esm/package.json",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was explicitly required to have package json in build dir ( lib ) to explicitly override module type for correctly loading ESM when required so I am generating here a package json in lib

packages/web3-core/tsconfig.esm.json Show resolved Hide resolved
packages/web3-core/package.json Outdated Show resolved Hide resolved
"build": "tsc --build",
"build": "yarn build:cjs && yarn build:esm && yarn build:types",
"build:cjs": "tsc --build tsconfig.cjs.json && echo '{\"type\": \"commonjs\"}' > ./lib/commonjs/package.json",
"build:esm": "tsc --build tsconfig.esm.json && echo '{\"type\": \"module\"}' > ./lib/esm/package.json",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need that for cjs dir

packages/web3-eth-accounts/package.json Outdated Show resolved Hide resolved
@@ -14,12 +14,14 @@ GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License
along with web3.js. If not, see <http://www.gnu.org/licenses/>.
*/
import { TransactionFactory } from '@ethereumjs/tx';
import defaultImport, * as fullImport from '@ethereumjs/tx';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doing this doesn't increase the build size?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it shouldn't, because there is one copy of this dependency in node_modules.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jdevcs But would this affect tree shaking since we're now importing everything and setting it to a const instead of just importing and using the TransactionFactory export?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this may not affect treeshaking as in case of ESM usage of our lib , dependency usage tree is still construable for module being used.

import defaultImport, * as fullImport from '@ethereumjs/tx';
const { TransactionFactory } = defaultImport || fullImport;

Even if any issue arise , the lib under discussion is decided to be removed, or we can upgrade this to latest @ethereumjs/tx where these exports are fixed as mentioned earlier:

This export problem is fixed in @ethereumjs/tx in 4.x and we can upgrade to that in our 4.x after reviewing breaking changes in another PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4.x 4.0 related
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants