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 7:56pm
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
Just made some bad experience with publishing npm packages under a certain name, so I am always snugging the npm package name first before publishing anything useful :D
  • reply
  • like

October 27, 2019 at 6:19am
ok cool
  • reply
  • like
I don't have travis setup yet I will have to go through the settings but tests pass locally and I was able to release with the --no-ci flag
  • reply
  • like

October 28, 2019 at 3:27pm
I made a bit of an executive decision and change the package and repo name to semantic-release-plus I feel like it is more descriptive. I published a package that includes the commit filtering. It is a drop in replacement for semantic-release meaning you just uninstall semantic-release and install semantic-release-plus. NPM will complain about peer dependencies for the plugins. I am still deciding on how I want proceed with that. Here is all the relevant information:
Edited
  • reply
  • like
I am still considering updating the cmd name to semantic-release-plus rather than semantic-release. This would allow you to have both semantic-release and semantic-release-plus installed side by side
  • reply
  • like
Show more messages