Spectrum is now read-only. Learn more about the decision in our official announcement.


📦🚀 Fully automated version management and package publishing


Commit Filtering and Other Monorepo Requests

October 23, 2019 at 4:45pm

Commit Filtering and Other Monorepo Requests

October 23, 2019 at 4:45pm (Edited 3 years ago)
Starting this thread here to pull it out of the issues and focus on a fork and get some input before starting. See for additional context

October 23, 2019 at 4:49pm
  1. What to name it?
    • semantic-release-kraken
    • semantic-release-hounds
    • ... open to other suggestions
  2. Should we start from the existing semantic release or the next version they are currently working on? Has anyone looked into it yet? How hard is the conversion? How stable is it?
That's a good naming, haha :-) How do you plan to release that plugin? As a fork or standalone?
This would be a fork, we need to change the core of semantic-release
Like I wrote in my comment
Yep, willing to contribute (In about 2-3 weeks). My idea is to mirror semantic-release too keep it in sync. (so just writing update scripts for the original codebase, so that we can apply them every time the HEAD of this repository gets updated)
I dont know if is open to make this an experiment within semantic-release (new repo within the org) or if we should make a new repo/organization for it. As i personally don't want to get that far away from source. It could be named semantic-release-[extended,monorepo,flex]. I personally dont like codewords for naming. :D
Thanks , When you say just writing update scripts for the original codebase can you elaborate on that?
I hand't considered that we might be able to host this within the semantic-release organization. That is a good Idea but will wait to hear back from .
Also not a huge fan of codenames but also needed a differentiation from the standard repo and I didn't want it to be so narrow as monorepo as it is not specifically for a monorepo
I would recommend to make the fork on your side, this way you have more flexibility. Having it in a different org won't prevent to merge the change back in semantic-releasae if we choose to.
This is great! A little while ago I sent out a Google Form to see how many people wanted to contribute. I can notify them all that we are moving forward on a fork! 🎉
What about semantic-release-multi. I like semantic-release-flex as well.
as the required changes at the moment are minimal I would propose a solution that we can update regularly from the main repo:
Writing a script which applies the changes required is (in my mind) easier to manage. This script would search for a specific code Snippet and update it with the required changes. This would bring the huge benefit of updating quite easily to the upcoming semantic-release versions and we would know if something has gone wrong because the search snippet would not be found if it is updated in the root.
Further we can easily integrate changes to the main repo if required. It brings the extra burden of writing a script to do so but I think it will make it easier to maintain.
If you have another idea feel free to elaborate. This just came to my mind :)
What I would like to note is, if and how the yarn.lock file is updated?
I love to see a a script that keeps our code updated, but can I suggest that we postpone that until we've implemented the changes?
of course but all it basically is is search for file pattern in current implementation and update it.

October 25, 2019 at 6:45am
semantic-release-flex it is I will setup the org and repo now
I also check that there wasn't an existing package with this name :-)
You can send me your email address so I can give you rights for the npm org :) created it just yet so nobody else can get it.
- thanks Dan, I wasn't planning on putting semantic-release-flex under a scope but could be useful for some other things
Show more messages