Hello Mateo and Patrick, I introduced meta in the company I work for some time ago. I liked the idea of a monorepo with all the projects having a separate git project.
I have been looking for ways to improve the productivity here and I've been struggling a bit with meta as I can do something with ALL the projects but not with some of them (easily, that is). I wanted to introduce some way of filtering and I started looking around at the code and I quickly noticed that a lot of the args and options are parsed manually from the process.argv array.
I already prepared changes locally to replace those with the commander-way. So the first question is: is there a particular reason why the parsing has been done manually?
🤓🤓 Question 2
The second question is about the possibility of filtering the projects being worked on.
Use case
I want to update all projects that have a specific version of a dependency (or just a random fixed list of them) and perform several commands, for example:
checkout master
remove local changes
pull recent changes from master
open a new branch
apply changes to every repository
commit on every repository
publish the branch and finally open an MR
I have accomplished all this writing a script most of the time, but recently meta search appeared and I immediately saw the opportunity of joining that plugin with my needs here. Also, the method I used is very error-prone and passing --exclude or --exclude-only with every command quickly becomes annoying.
My first idea was to use the .ignore property in the .meta or .looprc files but to my surprise, both are completely ignored by meta and I found some places where the options to exclude/include files or directories is even actively removed 😢
After looking at the code, I noticed that the list of folders that every plugin works on is taken from the projects property on the .meta file. It would be easy to introduce some filtering logic there but there would be so many options and I wanted to check with you guys to see which (if any) you would prefer. My ideas:
(ab)use .meta or .looprc with the risk of users forgetting they have exclusions configured (could be worked around logging a warning on every command that informs the user of the exclusions)
use ENV variables, e.g. META_EXCLUDED_PROJECTS (same problem as above, the nice thing is that using commander gives this almost for free because option defaults can be also taken from env variables)
🤓 Question 1
Hello Mateo and Patrick, I introduced meta in the company I work for some time ago. I liked the idea of a monorepo with all the projects having a separate git project. I have been looking for ways to improve the productivity here and I've been struggling a bit with meta as I can do something with ALL the projects but not with some of them (easily, that is). I wanted to introduce some way of filtering and I started looking around at the code and I quickly noticed that a lot of the args and options are parsed manually from the
process.argvarray. I already prepared changes locally to replace those with the commander-way. So the first question is: is there a particular reason why the parsing has been done manually?🤓🤓 Question 2
The second question is about the possibility of filtering the projects being worked on.
Use case
I want to update all projects that have a specific version of a dependency (or just a random fixed list of them) and perform several commands, for example:
I have accomplished all this writing a script most of the time, but recently
meta searchappeared and I immediately saw the opportunity of joining that plugin with my needs here. Also, the method I used is very error-prone and passing--excludeor--exclude-onlywith every command quickly becomes annoying. My first idea was to use the.ignoreproperty in the.metaor.looprcfiles but to my surprise, both are completely ignored by meta and I found some places where the options to exclude/include files or directories is even actively removed 😢After looking at the code, I noticed that the list of folders that every plugin works on is taken from the projects property on the
.metafile. It would be easy to introduce some filtering logic there but there would be so many options and I wanted to check with you guys to see which (if any) you would prefer. My ideas:.metaor.looprcwith the risk of users forgetting they have exclusions configured (could be worked around logging a warning on every command that informs the user of the exclusions)Sorry for the super lengthy post.