You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
lerna publish from-git using a custom tagVersionPrefix (in my case, something with a / in it, like foo/v) correctly identifies packages that need to be published.
Note: I am not sure, at this time, if the / in the tag prefix is the culprit or if merely using any tagVersionPrefix is sufficient to trigger this behavior.
Current Behavior
lerna publish from-git using a custom tagVersionPrefix indicates that there are no packages that need to be published.
Possible Solution
I have been able to trace this issue back to this line in get-current-tags.js that makes a call out to npm-package-arg. When using the default tag prefix of v, this call returns the expected result and the publish command proceeds as expected.
However, npm-package-arg seems to think that non-standard tags (ie: ones using a custom tag prefix) are invalid, and returns an object with an undefinedname property, causing the publish command to incorrectly report that there are no packages eligible for publishing.
If npm-package-arg is unable to parse tags with custom prefixes, perhaps it is not a suitable fit for Lerna.
Steps to Reproduce (for bugs)
Set the same tagVersionPrefix option for the version and publish commands in lerna.jsonor use the same --tag-version-prefix flag when executing lerna version and lerna publish below.
With 1 or more commits representing changes to at least 1 package, run lerna version. Lerna should correctly create a new tagged commit using the desired tag prefix.
Running lerna publish from-git reports the following:
lerna notice cli v3.16.2
lerna notice from-git No tagged release found
lerna success No changed packages to publish
If, however, the function containing the line referenced above is updated to return a standard v1.2.3-formatted string:
functionlistPackageNames(result){returnresult.stdout.split("\n").map(tag=>{// return tag && npa(tag).name;// Return 'v' (the default prefix) + the version you're// intending to publish.return'v1.2.4';}).filter(Boolean);}
Expected Behavior
lerna publish from-git
using a customtagVersionPrefix
(in my case, something with a/
in it, likefoo/v
) correctly identifies packages that need to be published.Note: I am not sure, at this time, if the
/
in the tag prefix is the culprit or if merely using anytagVersionPrefix
is sufficient to trigger this behavior.Current Behavior
lerna publish from-git
using a customtagVersionPrefix
indicates that there are no packages that need to be published.Possible Solution
I have been able to trace this issue back to this line in
get-current-tags.js
that makes a call out tonpm-package-arg
. When using the default tag prefix ofv
, this call returns the expected result and thepublish
command proceeds as expected.However,
npm-package-arg
seems to think that non-standard tags (ie: ones using a custom tag prefix) are invalid, and returns an object with anundefined
name
property, causing thepublish
command to incorrectly report that there are no packages eligible for publishing.If
npm-package-arg
is unable to parse tags with custom prefixes, perhaps it is not a suitable fit for Lerna.Steps to Reproduce (for bugs)
Set the same
tagVersionPrefix
option for theversion
andpublish
commands inlerna.json
or use the same--tag-version-prefix
flag when executinglerna version
andlerna publish
below.With 1 or more commits representing changes to at least 1 package, run
lerna version
. Lerna should correctly create a new tagged commit using the desired tag prefix.Running
lerna publish from-git
reports the following:If, however, the function containing the line referenced above is updated to return a standard
v1.2.3
-formatted string:... then
lerna publish
works as expected.lerna.json
Context
I am currently unable to publish packages in a repository where custom
tagVersionPrefix
-es are used.Your Environment
lerna --version
3.16.2
npm --version
6.10.1
node --version
10.16.0
10.14.5
The text was updated successfully, but these errors were encountered: