-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configure for multiple package roots? #142
Comments
Hey there! We had the same need in our project. If you use From that on you'll be able to set the following in your {
...
"release": {
...
"monorepo": {
"dependencies": [
"path/from/root/lib1",
"path/from/root/lib2",
"path/from/root/common"
]
}
} I don't expect that this package here will be updated soon, but if it will, this how I've updated const onlyPackageCommits = async commits => {
const packagePath = await getPackagePath();
const { release } = await readPkg();
const dependencies = release?.monorepo?.dependencies || [];
debug('Filter commits by package path: "%s" and dependencies: %o', packagePath, dependencies);
const commitsWithFiles = await withFiles(commits);
const packageSegments = packagePath.split(path.sep);
const dependencySegmentsList = dependencies.map(dep => dep.split(path.sep));
return commitsWithFiles.filter(({ files, subject }) => {
const isRelevantFile = file => {
const fileSegments = path.normalize(file).split(path.sep);
// Check if the file is in the current package
const isInPackage = packageSegments.every(
(seg, i) => seg === fileSegments[i]
);
// Check if the file is in any of the specified dependencies
const isInDependencies = dependencySegmentsList.some(depSegments =>
depSegments.every((seg, i) => seg === fileSegments[i])
);
return isInPackage || isInDependencies;
};
const packageFile = files.find(isRelevantFile);
if (packageFile) {
debug(
'Including commit "%s" because it modified package file "%s".',
subject,
packageFile
);
}
return !!packageFile;
});
}; |
@pmowrer: Would this be something that you would be willing accept as a contribution to the current 8.x release? We would love to provide the changes and sync them back to your main repository instead of creating pnpm patches for this to work. |
This seems like a variation of a holy grail feature request that keeps coming up - automating the release of dependent packages. #96 (comment) Usually, an expectation is that dependent packages are auto-bumped and released but in the past I've deemed that level of orchestration to be well outside the scope of this tool given its just a In this case, it doesn't seem like release orchestration is a requirement so I'd be willing to consider it, though I would expect more requests for that type of feature to come in if incorporating this. Does |
So from our implementation, it is not about any kind of
In the initial case of:
You would just add the following for
So whenever there's a change in So the mindset is less:
|
Implementation aside, shouldn't there be |
Yah, we've set up a
Of course you could lean on that, like checking the current name of the package and looking if it appears in the dependencies or dev dependencies. At least this would open a lot more possibilities than the current state. I personally enjoy the ability to control things, e. g. like to select that a release is only triggered if e. g. there are changes for specific folders which might even don't have a |
I think this would be the way to go for a standardized solution, though I'd worry it would be half-baked workflow. I'd expect to get feature requests for release orchestration again.
I hear you. In general, as a library author, I'd want to avoid introducing options to cater to bespoke workflows. To make it a general solution, we'd probably want allow providing a custom commit filtering solution altogether. When I first looked into monorepo workflows with Unfortunately, that PR (along with all other monorepo suggestions) were shot down, resulting in this library. Perhaps we could expose |
Hi there,
I've been using semantic-release in a monorepo for the past year, releasing the final builds under a single version (generated by SR). I've now reached the point where I want to split individual components off and version them independently. One problem I am facing with this is that I have several shared code projects within the repo, and touching just these shared code directories, as far as I can tell, will not actually trigger
semantic-release-monorepo
into creating a release for any other projects that depend on this shared code.Is it possible to configure it to do so?
A (more visual) example of what I mean:
While I'm not very experienced in the realm of repo management, I would be happy to attempt implementing this if it is not currently supported (and would be accepted by the maintainer(s)). Thanks!
The text was updated successfully, but these errors were encountered: