Great tool if you know what you are doing :) However, there is a threat of overusing it. I think only the complex scripts need to go into a separate file, otherwise, there will be many unnecessary files, which will create a mess for someone not very well aware of the project structure. Moreover, here is a case when there is a need to find the script which does what you intend to do. In some repositories, the starting script may be named as start, in the others, it may be called dev or development, or there may be a 3-rd party lib starting up the project for the others, so, in case the person is new in the project, they need to scan over the scripts to understand which one they need. This separation may be an additional difficulty for them.
I think this will work best for small teams or projects with good documentation, otherwise it may become a problem itself.
I often pick this tool for my personal projects just for the convenience.
But I do agree, I had a monorepo where I have a common scripts which runs a common test command and then inside the folders when I don't need to pass any special flag I only navigate back and invoke the bash script.
I don't have this workflow documented because it's my projects I don't believe nobody will ever touch it but I strong believe in good and well maintained documentations explaining such workflows.
At Warner for example we work in a very complex monorepo with more then 30 projects cross 10 different teams. The work flow, how to setup, the why's of the tooling we use there is all written in .md files and it can help everyone understand the decisions taken.
But I've worked in places where we had some scripts here and there, no docs nor reference explaining why and I needed indeed to scan to understand.
Maybe it's more about how do we organize ourselves and think of the team then the tool we're using.
But you brought a valid point... thanks for that :D
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great tool if you know what you are doing :) However, there is a threat of overusing it. I think only the complex scripts need to go into a separate file, otherwise, there will be many unnecessary files, which will create a mess for someone not very well aware of the project structure. Moreover, here is a case when there is a need to find the script which does what you intend to do. In some repositories, the starting script may be named as
start, in the others, it may be calleddevordevelopment, or there may be a 3-rd party lib starting up the project for the others, so, in case the person is new in the project, they need to scan over the scripts to understand which one they need. This separation may be an additional difficulty for them.I think this will work best for small teams or projects with good documentation, otherwise it may become a problem itself.
I often pick this tool for my personal projects just for the convenience.
But I do agree, I had a monorepo where I have a common scripts which runs a common
testcommand and then inside the folders when I don't need to pass any special flag I only navigate back and invoke the bash script.I don't have this workflow documented because it's my projects I don't believe nobody will ever touch it but I strong believe in good and well maintained documentations explaining such workflows.
At Warner for example we work in a very complex monorepo with more then 30 projects cross 10 different teams. The work flow, how to setup, the why's of the tooling we use there is all written in
.mdfiles and it can help everyone understand the decisions taken.But I've worked in places where we had some scripts here and there, no docs nor reference explaining why and I needed indeed to scan to understand.
Maybe it's more about how do we organize ourselves and think of the team then the tool we're using.
But you brought a valid point... thanks for that :D