(Draft): Feature/remove lerna

[taranek]

What kind of change does this PR introduce?

The intention is to remove lerna from dependencies list and use yarn workspaces instead. I started with removing lerna bootsrap command to see if yarn install would suffice for pipelines to succeed.

After replacing lerna bootstrap, I'll have a look on other lerna usages (versioning and publishing) to see how we can replace those.

Did you add tests for your changes?

No

If relevant, did you update the documentation?

Not yet, I'd like to run a few CI pipelines on my branch to see how it goes.

Summary

Related to feature request #3227

Does this PR introduce a breaking change?

No

Other information

This is a draft PR, as migration from lerna is not ready yet.

[codecov[bot]]

Codecov Report

Merging #3252 (adfdc51) into master (3b0e6ea) will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #3252   +/-   ##
=======================================
  Coverage   92.08%   92.08%           
=======================================
  Files          23       23           
  Lines        1731     1731           
  Branches      519      519           
=======================================
  Hits         1594     1594           
  Misses        137      137           

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 3b0e6ea...adfdc51. Read the comment docs.

[alexander-akait]

Just intresting why not use npm/yarn/pnpm workspace feature?

[taranek]

@alexander-akait I am using yarn workspaces feature here - most of the setup was already done, as lerna uses yarn workspaces under the hood.

[alexander-akait]

Looks good for me

[alexander-akait]

The main problem will be here https://github.com/webpack/webpack-cli/blob/adfdc51bd24b24d3e851904ee3751939438aa4c0/package.json#L46

[taranek]

@alexander-akait Yes, it seems like we'll need an external dependency if we want to preserve the current flow, let me describe it in detail by breaking down lerna.json configuration file:

{
 // ... rest of the config
  "command": {
    "version": {
      "message": "chore(release): publish new version", // 1. commit message template to use when publishing
      "conventionalCommits": true, // 2. generate `CHANGELOG.md` file based on commits included in the current version
      "allowBranch": ["master", "next"] // 3. allow versioning only on particular branch name
    }
  }
}

Whereas features 1. and 3. can be achieved via preversion or postverion npm package hooks or simple bash scripts, we can't generate changelog without adding a dependency. We can either install a small library to generate changelog and handle the release process by ourselves or introduce a bigger dependency, like e.g. semantic release which can handle both prerelease, postrelease hooks along with generating changelog and determining webpack version.

@alexander-akait What do you think? Which option seems to be better?

[alexander-akait]

@taranek Good question, I haven't studied in detail but isn't there built-in mechanism in yarn workspaces? I think it is possible:

• use small library to generate changelog
• run built-in yarn workspace features to do release

And we can update our docs to provide instructions, so any developer can do release without problems

[taranek]

@alexander-akait Yeah, I was mostly concerned about generating changelog files, which I guess it's not possible in yarn workspaces. I'll have a second look on the current publishing flow and will propose a suitable solution with a small dependency.

[alexander-akait]

:+1: Also we can create small script to generate changelog (even more we can copy code from lerna to achive it)

[taranek]

@alexander-akait One more thing that we need to take care of is resolving the next release's version number - the lerna version command does it by using the conventional commits strategy. TBH I'm not sure if it's worth solving these problems (generating changelog, versioning, publishing) by ourselves/

I'd rather go with an external dependency instead of reinventing the wheel - it's just an additional code we'll need to maintain. Also, our release setup is one of the simplest possible - I would understand creating customised solution in order to improve performance of the releasing process, but in this case, I think there's really no need to do so 🤔

[snitin315]

I suppose we can use changesets for managing reeases

[alexander-akait]

@taranek

I'd rather go with an external dependency instead of reinventing the wheel - it's just an additional code we'll need to maintain.

Sounds good

[rishabh3112]

ping @alexander-akait

[alexander-akait]

@rishabh3112 I am still thinking we should replace lerna on built-in workspace feature of npm/yarn/pnpm, it is faster, more stable and ligth

[rishabh3112]

I am still thinking we should replace lerna on built-in workspace feature of npm/yarn/pnpm, it is faster, more stable and

Okay, Makes sense. @webpack/cli-team lets keep this open to explore more solutions into this.

[alexander-akait]

Let's close and maybe revisit it late, I don't think we have a lot of time to migrate, anyway I think we will do migration when we decide to use update yarn to the latest version or migrate on other package manager, because workspaces are built-in now