Using squashed commits for releases results in lerna publish listing all packages #1345
Comments
|
You're deleting the tag, so lerna has literally no idea what the diff from the "last release" was. (Squashing would mangle the tag anyway) Why not wait until the PR is merged to publish? I don't understand encumbering the developer with |
We're doing this - we're publishing from master after merge, we delete the tag that's created by Lerna but this is created later with the same name by GitHub via the GitHub releases interface. However you've made me realise that the issue is that I didn't have all tags locally when I was running Thanks for your help 🙂 |
lerna uses tags to determine what has changed, we need to make sure we have all tags locally see lerna/lerna#1345
lerna uses tags to determine what has changed, we need to make sure we have all tags locally see lerna/lerna#1345
Fixes #175 (hopefully) Updates to a devDependency for a package causes `lerna publish` to republish that package. This has a knock on effect throughout our repo meaning a single change to one component can result in every component being republished. We don't want this to happen so are including most devDependencies at the project root (where we expect these dependencies are only used when using the package as part of a monorepo). Exceptions are where a component has specific peerDependencies and we want to also represent that in the devDependencies. Related: lerna/lerna#1269 lerna/lerna#1345 import-js/eslint-plugin-import#935
|
This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Our Workflow
lerna publish --skip-npmon a branch of master and opens a pull request with the version increment.v1.0.0 (#101)which is the Lerna generated version number followed by the GitHub pull request ID.Expected Behavior
After following the workflow above, I would expect
lerna updatedto list no new changes on master immediately after a release.Current Behavior
All packages are listed as containing changes, I assume because Lerna is looking for a commit message of
v1.0.0for a release, and does not matchv1.0.0 (#101).Possible Solution
When looking for published versions in commit messages, match an optional pull request ID following the version number (e.g.
v1.0.0 (#101)) with a regex.Steps to Reproduce (for bugs)
Our release process is here.
This is partially scripted here.
lerna --versionnpm --versionyarn --versionnode --versionThe text was updated successfully, but these errors were encountered: