LERNA.md

Yarn - Lerna

Questions:

• Is it easier to keep the same version in all shared lib packages?
• If lerna publish happens only in master/CI, how do we update dependencies in feature branches? should we push to master first, then update?

Option 1: no yarn lock file

• All @TUO package dependencies are marked as version ^1.0.0 in their packages/*/package.json
• All Public packages have fixed versions (ie. 1.2.3)
• The yarn.lock file is not pushed
• Package versions are updated manually by running lerna version

Versions can be updated locally: yes. Developers need to run yarn install --force or lerna bootstrap

Versions can be updated on a feature branch: yes. Developers need to run yarn install --force or lerna bootstrap

Publishing works in the CI: yes. Lerna publish with no git options does not need to update the yarn.lock or packages/*/package.json

Pros:

• When packages need to be updated, Lerna in Gitlab does not need to update the lock, which is currently not possible due to lack of git user

Cons:

• Fixes or updates from public packages cannot be obtained without manually bumping versions in the package.json files
• Versions are not controlled and fixed at commit time (even if versions will stay fixed throughout the build process as the Docker image running the yarn install is built once)

Option 2: Lerna

• Lerna manages package versions via conventional-commits. When a fix/feat/breaking change is pushed in the commit message, Lerna determines the version number to use to

Versions can be updated locally: no Lerna manages bumping version from the master branch only

Versions can be updated on a feature branch: not directly

• Lerna manages bumping version from the master branch only
• Developers use RC versions and push them from local and update the lock for the consumers

Publishing works in the CI: yes. Lerna publish uses the conventional commits to detect next versions

Pros

• No need to manage version bumps manually

Cons:

• Cannot be implemented in Gitlab due to lack of git user
• To develop on a feature branch, changes to another dependent package have to go through master first, so that the yarn dependency on this package can be updated in the feature branch

Option 3: Peer dependencies

• All @TUO package dependencies are placed into peerdependencies instead of dependencies
• The consumer needs to reference the new version

Cons

• Peer dependencies versions to be updated manually

Option 4: lerna-update-wizard

• Packages are published via lerna
• Dependencies are bulk updated in yarn.lock using lerna update wizard

Versions can be updated locally: not directly Lerna needs to publish to the NPM registry first, so that lerna-update-wizard can detect all latest versions before updating the lock file

Versions can be updated on a feature branch: not directly Lerna needs to publish to the NPM registry first, so that lerna-update-wizard can detect all latest versions before updating the lock file

Publishing works in the CI: no lerna-update-wizard requires a git user

Option 5: no lerna, only yarn

• After making a change to a package, the package version is bumped manually at the package level (with yarn publish (--minor))
• With a lock file, it would update the lockfile and developer will just run yarn install
• Without a lock file, developer will just run yarn install --force

Cons

• Bump manually the package versions
• yarn upgrade of each dependency versions in consumer packages

Option 6: yarn workspaces / yarn publish at the root level

To be confirmed