Possible improvements to resolve some irritants when working with Lerna

[gaelhameon]

Hi,
I'm currently still using lerna for the release workflow of my Monorepo, mainly because I use the conventional commits flag.

From what I understand, the Yarn Release Workflow, does not offer a way of automatically deciding version bumps based on commit messages.

• Am I mistaken on that ?
• Does anybody know of yarn plugins that make this possible ?

Assuming the answer to both my previous questions is no, I think I'll keep using Lerna in the short/medium term.

I currently have two issues with this:

1. Lerna fails when it encounters workspaces: resolutions
2. After a Lerna Publish cycle, I have to manually do a new yarn install and a separate commit to update the yarn.lock file

The first issue is the most irritating. I would like to be able to just yarn add package-name to let yarn take care of specyfing dependencies in package.json, and it actually works fine, until I have to do anything that relies on Lerna, which will complain with this:

lerna ERR! Error: Unsupported URL Type "workspace:": workspace:path/to/workspace

So at this point I have to manually figure out the latest version of each of my packages and manually replace them in all of my package.json files, which is very tedious.

So right now, instead of doing that, I basically just stopped using yarn add, and I manually add my dependencies in package.json, which is also tedious, but in smaller bits ...

Ideas for improvements:

• add an option to yarn add that would prevent it from using the "workspaces" protocol
• change the behavior of one of the existing options: for example, when using -C or -T, we could assume that if the user took the time to specify they want a caret, they probably don't want to use the "workspaces" protocol
• a variation of the two above, that would be controlled in yarnrc.yml, so you don't have to type an additional option every time you use yarn add
• refactor/modify the pack plugin to extract the beforeWorkspacePacking hook and make it available to other plugins, so that a new command could be used to change the protocols, but stop there and leave the changes in the working tree, instead of packing

What do you think of these ideas ? If I were to work on a pull request to implement one of those, would you consider merging it ?

Regarding the second issue, its not as bad and I haven't really looked into it so far, but if anybody has a similar problem and ways to solve it, I'd be happy to hear !

Thanks in advance