[Feature] Per-package version flags for independently versioned publishing #389
Comments
|
We've discussed this before, @hzoo do you remember what APIs were suggested for this? |
jamiebuilds
changed the title
|
Might of been a while ago so I forgot - just that users wanted to specify versions before hand for CI and I wanted to use something like semantic release as well (github labels/commit message) |
|
if it helps at all, we've frankenstein-ed together some scripts to assist us with this manually. We basically print out what we believe the new versions should be, which we could then use to manually update lerna. I'd love to be able to turn these tables into a machine-readable format which we could pass off to lerna, whether that's by formatting them as CLI flags or some other method. |
|
The other option we have here is to allow people to update the versions in their It could even be automated by a separate command: $ lerna pre-publish
# interactive version updates
# in CI:
$ lerna publish # maybe doesn't need flag?
# no need for interactive bits |
|
Any update/workaround on this? |
|
No progress that I'm aware of. Does #607 solve this issue? |
|
It might. but i'm not sure how. |
This is probably going to change in the future but for now I need this to publish from CI. Possible fixes for this is to implement this[1] or force conventional commits. Conventional commits might not be that bad actually so I'll think about it a bit more [1]: lerna/lerna#389 (comment) [2]: https://github.com/lerna/lerna#--conventional-commits
|
@vampolo Using --skip-git in combination with --skip-npm works better? |
|
Would love to see this implemented. Unfortunately, I don't have the time to implement this myself, however, I wanted to share a somewhat hacky solution to programmatically update independently versioned packages. I created a POC script which given a map of package names pointing to a number representing the location of the bump strategy on the prompt, will programmatically answer the prompt. Needless to say, this is very hacky, as arbitrary changes to how the prompt is presented could break this script. import childPty from 'child_pty';
import { EOL as ENTER } from 'os';
const PATCH = '1';
const MINOR = '2';
const MAJOR = '3';
const publish = childPty.spawn('yarn', 'lerna publish'.split(' '));
/* package to bump strategy map */
const updateMap = {
'@xo-union/sdk-membership': MINOR,
'@xo-union/store-conversations-redux': MAJOR,
'@xo-union/store-membership-redux': PATCH,
'@xo-union/store-membership': MINOR,
'@xo-union/tk-component-core-provider': MAJOR,
'@xo-union/tk-component-header-nav-redux': MINOR,
'@xo-union/tk-component-membership-modal-redux': PATCH,
'@xo-union/tk-component-vendor-card': MAJOR,
'union-release': PATCH
};
const alreadyAnswered = {};
publish.stdout.on('data', (data) => {
const string = data.toString('utf8');
const waitingForAnswer = string.indexOf('Select a new version for') >= 0;
if (waitingForAnswer) {
const packageName = string.match(/Select a new version for ([^\s]+)/)[1];
if (!alreadyAnswered[packageName]) {
const key = updateMap[packageName];
publish.stdin.write(key);
publish.stdin.write(ENTER);
alreadyAnswered[packageName] = true;
}
}
if (string.indexOf('Are you sure you want to publish the above changes?') >= 0) {
/* Start accepting input, to allow user to confirm */
process.stdin.on('data', (data) => publish.stdin.write(data));
/**
if continous deployment:
publish.stdin.write('y');
publish.stdin.write(ENTER);
**/
}
process.stdout.write(data);
});
publish.on('close', function () {
process.stdin.pause();
}); |
|
I would think `--conventional-commits` solves this in a more automated fashion.
… On Jan 25, 2018, at 23:48, George ***@***.***> wrote:
Would love to see this implemented. Unfortunately, I don't have the time to implement this myself, however, I wanted to share a somewhat hacky solution to programmatically update independently versioned packages. I created a POC script which given a map of package names pointing to a number representing the location of the bump strategy on the prompt, will programmatically answer the prompt. Needless to say, this is very hacky, as arbitrary changes to how the prompt is presented could break this script.
import childPty from 'child_pty';
import { EOL } from 'os';
import { Subject } from 'rx';
const enter = EOL;
/* Option number in prompt */
const PATCH = '1';
const MINOR = '2';
const MAJOR = '3';
const publish = childPty.spawn('yarn', 'lerna publish'.split(' '));
/**
map of packages to bump strategy
*/
const updateMap = {
***@***.***/sdk-membership': MINOR,
***@***.***/store-conversations-redux': MAJOR,
***@***.***/store-membership-redux': PATCH,
***@***.***/store-membership': MINOR
};
const alreadyAnswered = {};
const answers = new Subject();
publish.stdout.on('data', (data) => {
const string = data.toString();
const waitingForAnswer = string.indexOf('Select a new version for') >= 0;
if (waitingForAnswer) {
const packageName = string.match(/Select a new version for ([^\s]+)/)[1];
if (!alreadyAnswered[packageName]) {
answers.onNext(updateMap[packageName]);
answers.onNext(enter);
alreadyAnswered[packageName] = true;
}
}
if (string.indexOf('Are you sure you want to publish the above changes?') >= 0) {
answers.onCompleted();
}
process.stdout.write(data);
});
const subscription = answers.subscribe({
onNext([ key ]) {
publish.stdin.write(key);
},
onCompleted() {
subscription.dispose();
/* wire stdin to allow user to confirm changes */
process.stdin.on('data', (data) => publish.stdin.write(data));
}
});
publish.on('close', function () {
process.stdin.pause();
});
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@evocateur You are right but adopting conventional commits means forcing developers into the conventional commit workflow (for both developers and reviewers) that could cause confusion and production issues if not monitored carefully. We are weighing that option against an option to use a simpler method of storing the next-release metadata in YAML files, which has the benefit of being simpler to review (as our developers primarily focus on reviewing files in PRs), and simpler to edit in the case of mistakes.
|
|
Oh yeah, I definitely understand that commit message formats are really hard to scale across a dev org with widely varying experience/interest/workflows. Many of the tools I’ve seen to mitigate this (commitlint, cz, etc via git hooks) have the drawbacks of being Yet Another Tool and aggravating users with rejected pushes/commits.
|
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
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. |
We've been using Lerna to develop Material Design Lite v2, and it's been working out extremely well for us. We independently version all of our components, with
packages/material-design-litemirroring the overall version of our monorepo.As we near our initial release, we're starting to focus on release infrastructure. While lerna takes care of pretty much all the heavy lifting around tagging/publishing for us, one thing I've noticed is that while you can programmatically specify a singular overarching version for all packages via
--repo-version, there doesn't seem to be a way to specify per-package versions in the same manner.Just at alpha, we already have ~20 packages. Entering versions for each one at a prompt could be quite time-consuming and error-prone for us, especially when trying to determine the optimal version change for an update spanning multiple commits for multiple packages. I've written some ideas on ways we can minimize the work we have to do for this in an issue comment, but that still involves manually entering a version.
I was wondering if the team would consider adding a flag similar to
--repo-version, perhaps something along the lines of--package-versions, which could be used to programmatically specify versions for each package.For example:
or
or
and/or
This would allow teams like us to programmatically determine package versions, and then provide them to lerna.
I've (crappily) sketched out what a high-level implementation for this could look like below:
packagesToUpdatebe the collection of packages returned fromUpdatedPackagesCollector--package-versionsis specified--repo-versionalso specified, errorpackageVersionsbe an object where each key is a package and each value is a version(package, version)specified in--package-versionspackagecannot be found in packages dir, errorpackageVersions[package]is already defined, error (?)packageVersions[package] = versionpackagesNeedingPromptbe the intersection ofpackagesToUpdateand the keys ofpackageVersionsI'd be happy to help out with this as it would help out a lot with our release workflow. Another (much simpler) alternative could be to add support for omitting auto-tagging and assume the end user has already manually tagged all sub-packages. This, however, could be more error-prone than a solution integrated directly into lerna.
As an FYI, we've also looked at lerna-semantic-release, but we don't use
cz-lerna-changelog(we usecz-conventional-changelog), there isn't much docs on how exactly the releases work, and we're still a bit wary of fully-automated releases until the project stabilizes.The text was updated successfully, but these errors were encountered: