menu
Channels
Team

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 12 months ago)
Starting this thread here to pull it out of the issues and focus on a fork and get some input before starting. See https://github.com/semantic-release/semantic-release/issues/193 for additional context
Show previous messages

October 23, 2019 at 5:35pm
That's a good naming, haha :-) How do you plan to release that plugin? As a fork or standalone?
Edited
  • reply
  • like
This would be a fork, we need to change the core of semantic-release
  • reply
  • like
Like I wrote in my comment
  • reply
  • like
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)
  • reply
  • like
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
Edited
  • reply
  • like
Thanks , When you say just writing update scripts for the original codebase can you elaborate on that?
  • reply
  • like
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 .
  • reply
  • like
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
  • reply
  • like
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.
  • reply
  • like
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! 🎉
  • reply
  • like
What about semantic-release-multi. I like semantic-release-flex as well.
  • reply
  • like
as the required changes at the moment are minimal I would propose a solution that we can update regularly from the main repo:
  • reply
  • like
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.
  • reply
  • like
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.
  • reply
  • like
If you have another idea feel free to elaborate. This just came to my mind :)
  • reply
  • like
What I would like to note is, if and how the yarn.lock file is updated?
  • reply
  • like
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?
like-fill
2
  • reply
  • like
currently there is none
  • reply
  • like
of course but all it basically is is search for file pattern in current implementation and update it.
  • reply
  • like

October 25, 2019 at 6:45am
semantic-release-flex it is I will setup the org and repo now
  • reply
  • like
I also check that there wasn't an existing package with this name :-)
  • reply
  • like
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.
  • reply
  • like
  • reply
  • like
- thanks Dan, I wasn't planning on putting semantic-release-flex under a scope but could be useful for some other things
  • reply
  • like
Show more messages