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

monorepo: replace lerna with npm workspaces #1395

Merged
merged 6 commits into from
Aug 11, 2021
Merged

Conversation

ryanio
Copy link
Contributor

@ryanio ryanio commented Aug 9, 2021

This PR updates the monorepo from using lerna to npm workspaces, simplifying dev ux by removing the need for bootstrapping.

Typescript project references are used for linking packages during build time.

Run scripts in specific packages at root with e.g. npm run docs:build --workspace=@ethereumjs/vm or in all packages with --workspaces.

@codecov
Copy link

codecov bot commented Aug 9, 2021

Codecov Report

Merging #1395 (5f307bd) into master (587ee70) will increase coverage by 1.19%.
The diff coverage is n/a.

Impacted file tree graph

Flag Coverage Δ
block 86.60% <ø> (ø)
blockchain 83.43% <ø> (-0.07%) ⬇️
client 83.38% <ø> (-0.48%) ⬇️
common 94.17% <ø> (-0.23%) ⬇️
devp2p 83.24% <ø> (+0.07%) ⬆️
ethash 82.83% <ø> (ø)
tx 88.36% <ø> (ø)
vm 82.79% <ø> (+3.45%) ⬆️

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

@ryanio ryanio force-pushed the npm-workspaces branch 2 times, most recently from c84fca9 to d141ad9 Compare August 10, 2021 00:25
@ryanio ryanio force-pushed the npm-workspaces branch 2 times, most recently from 3103ef2 to 289f878 Compare August 10, 2021 00:53
@holgerd77
Copy link
Member

Great, that sounds really promising on first sight! 😄

Several questions here:

  1. If I understand correctly npm is at least somewhat attached to a specific Node version (or is this not correct, always thought so?) So do I then always have to run some latest Node version here? And does this more broadly affect the ability to test with different Node versions?
  2. Are users of the packages - apart from devs directly working on the monorepo - in any way enforced to use npm 7?
  3. npm run docs:build --workspace=@ethereumjs/vm: so is it not possible any more to run npm run docs:build from the package folder? I would find this pretty inconvenient especially for things like testing.

@acolytec3 acolytec3 self-requested a review August 10, 2021 10:14
@holgerd77
Copy link
Member

Let's please wait until the next EthereumJS call until we merge this in.

@holgerd77
Copy link
Member

(doesn't mean that this can't be reviewed yet of course)

Copy link
Contributor

@acolytec3 acolytec3 left a comment

Choose a reason for hiding this comment

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

Once I installed the correct version of NPM and completely blew away the repo and started from scratch, everything seems to work fine and I like not having lerna around anymore. :-)

A couple of general comments/questions before approving:

  1. I think we need to somehow specify in MONOREPO.md that you need to be on NPM version 7 to make contributions to the project. npm i threw errors when I tried to run it without being on npm7 but there weren't any obvious error messages telling me what was wrong.
  2. What do you think about adding back the global lint/test scripts in the monorepo package.json? I ran both and (admittedly test is still running) they seem to work so might be nice to have those global scripts available.
  3. I noticed that the packages/client/dist/bin/cli.js file isn't being ignored after running npm run build --workspaces from the root. Is this a necessary file for CI purposes? I guess it's probably not a big deal but it could be a pain to deal with if we have that file sneaking into every new commit to the client package.

@ryanio
Copy link
Contributor Author

ryanio commented Aug 10, 2021

Thanks guys for taking an initial look! I'm excited for these improvements.

  1. If I understand correctly npm is at least somewhat attached to a specific Node version (or is this not correct, always thought so?) So do I then always have to run some latest Node version here? And does this more broadly affect the ability to test with different Node versions?

Yes usually a Node version has a specific npm version bundled with it (see this table).

It's easy to upgrade to use npm v7 though regardless of the node version you are on, simply npm i -g npm@7, which I am doing in the ci.

  1. Are users of the packages - apart from devs directly working on the monorepo - in any way enforced to use npm 7?

I don't think so, only developers of the monorepo.

  1. npm run docs:build --workspace=@ethereumjs/vm: so is it not possible any more to run npm run docs:build from the package folder? I would find this pretty inconvenient especially for things like testing.

Yes you still can run it in a package folder, this is just a convenience when on root level to specify which package(s) the cmd should run.


Once I installed the correct version of NPM and completely blew away the repo and started from scratch, everything seems to work fine and I like not having lerna around anymore. :-)

wohoo

  1. I think we need to somehow specify in MONOREPO.md that you need to be on NPM version 7 to make contributions to the project. npm i threw errors when I tried to run it without being on npm7 but there weren't any obvious error messages telling me what was wrong.

Yes this is actually what I was trying to do with the engines -> npm field but it just outputs a small warning instead of halting. Good point though, I will add extra documentation and I'm also thinking of adding a preinstall script that will grep npm -v and exit with a friendly error suggesting to do npm i -g npm@7 if <v7 for workspaces support.

  1. What do you think about adding back the global lint/test scripts in the monorepo package.json? I ran both and (admittedly test is still running) they seem to work so might be nice to have those global scripts available.

I can add them back, it's a bit redundant though, because you can just run the script you want e.g. npm run lint:fix --workspaces to run the cmd (I updated the documentation to reflect this). I thought it was a bit redundant to add it to the root package.json and also it screws up if you want to run e.g. npm run lint:fix --workspace=@ethereumjs/vm then it would call the root script to run in all packages.

  1. I noticed that the packages/client/dist/bin/cli.js file isn't being ignored after running npm run build --workspaces from the root. Is this a necessary file for CI purposes? I guess it's probably not a big deal but it could be a pain to deal with if we have that file sneaking into every new commit to the client package.

I was having a bit of trouble with this one, without that file present npm install was trying to chmod the file since it is defined as a bin path in client/package.json - and it was erroring out on 404 since the file is not present before building - I'm going to fiddle around with this one this morning and see if I can get a better/cleaner solution that does not need to define that file as a placeholder since as you mention it doesn't work when the file gets updated with code then tries to check into git.

@ryanio
Copy link
Contributor Author

ryanio commented Aug 10, 2021

ok, I wrote a nice little preinstall script to assist with npm version detection that outputs either:

npm >=v7 satisfied

or:

npm version 7 or greater is required for workspaces support. Please update with "npm i -g npm@7"

will push up a commit along with some other updates this afternoon.

…esolved chmod error with preinstall script workaround)
@@ -34,17 +34,20 @@ jobs:
uses: actions/cache@v2
id: cache
with:
key: Block-${{ runner.os }}-${{ matrix.node-version }}-${{ hashFiles('**/package-lock.json') }}
key: cache-${{ runner.os }}-${{ matrix.node-version }}-${{ hashFiles('**/package-lock.json') }}
Copy link
Member

Choose a reason for hiding this comment

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

I believe the latest version of actions/setup-node does this automatically for you. I haven't tried that yet, but looks promising.

https://github.com/actions/setup-node#caching-packages-dependencies

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oh, nice, thanks! that does look a lot simpler. let me give it a try.

@acolytec3
Copy link
Contributor

LGTM!

@@ -1,6 +1,12 @@
{
"name": "root",
"private": true,
"workspaces": [
"packages/*"
Copy link
Member

Choose a reason for hiding this comment

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

There is the ethereumjs-testing submodule implicitly included here, might this have any side effects?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

that's a great point, it does seem to be ignoring it so far as a workspace.

when running commands at root with --workspaces the command is not executed in ethereumjs-testing.

@holgerd77
Copy link
Member

Also gave this a brief review, looks really great! 😄 🎉 Will be brave and directly merge.

@holgerd77 holgerd77 merged commit 66d02e1 into master Aug 11, 2021
@holgerd77 holgerd77 deleted the npm-workspaces branch August 11, 2021 20:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants