So, without wanting to sound flippant, what's the one command that someone who has only just checked out the repository can run to achieve all of that? And the one command that can be run before a commit - to make sure that I've not introduced any breaking changes in the commit I'm about to do?
It looks like it's npm run prepush, but it's not obvious to me.
And this is exactly my point. It's not obvious, because there is so much flexibility and so many different ways to achieve things.
In the Java/Maven world, I know that I can run mvn install on any project to run the complete build/test/etc lifecycle. This one command will:
Download all of the dependencies
Run all static checks
Perform any code generation steps needed
Perform any resource generation steps needed
Compile all of the code - main and test
Package everything up correctly
Run all of the tests - unit and integration
Additionally, if I ran mvn site then it will build the full set of documentation for the project. And if I instead ran mvn deploy then it will deploy the output to the configured destination - e.g. putting artifacts into Archiva, sending the actual application to Heroku, sending the built site to S3, etc.
And all of this works exactly the same on a single module or across a multiple-module build.
And the Integration tests can include steps to start and stop dependant services if needed - e.g. docker containers, the actual service under test, etc.
And packaging everything up can include into WAR files, executable JAR files, Docker containers, whatever is needed.
But the key thing is - I don't have to think about it. As someone new to the project, I already know how to work with it. As someone doing day-to-day work with it, it's easy.
(And, before you say, I know a bunch of that is because it's what I know, and that if I was more used to Node, or Python, or something like that then this would probably seem overly complex and that language would seem simpler.)
Super interesting. Like I said, I have next to no practical experience with Java, and the Java ecosystem, so it looks like I misunderstood exactly what you meant. What you are describing is very cool. I guess you summed it up nicely when you said:
there is so much flexibility and so many different ways to achieve things.
And that is a problem in the JavaScript universe, not only with build processes, but with pretty much every aspect of coding and development. It's the whole convention vs. configuration thing and in the JavaScript world, we are big time in the configuration side of things. There are so many ways to do everything. JavaScript fatigue is a real thing.
So you definitely have a point; you can't expect that running npm build on one JS project, will have the same impact as running npm build on another JS project. There is no convention when it comes to that.
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.
So, without wanting to sound flippant, what's the one command that someone who has only just checked out the repository can run to achieve all of that? And the one command that can be run before a commit - to make sure that I've not introduced any breaking changes in the commit I'm about to do?
It looks like it's
npm run prepush, but it's not obvious to me.And this is exactly my point. It's not obvious, because there is so much flexibility and so many different ways to achieve things.
In the Java/Maven world, I know that I can run
mvn installon any project to run the complete build/test/etc lifecycle. This one command will:Additionally, if I ran
mvn sitethen it will build the full set of documentation for the project. And if I instead ranmvn deploythen it will deploy the output to the configured destination - e.g. putting artifacts into Archiva, sending the actual application to Heroku, sending the built site to S3, etc.And all of this works exactly the same on a single module or across a multiple-module build.
And the Integration tests can include steps to start and stop dependant services if needed - e.g. docker containers, the actual service under test, etc.
And packaging everything up can include into WAR files, executable JAR files, Docker containers, whatever is needed.
But the key thing is - I don't have to think about it. As someone new to the project, I already know how to work with it. As someone doing day-to-day work with it, it's easy.
(And, before you say, I know a bunch of that is because it's what I know, and that if I was more used to Node, or Python, or something like that then this would probably seem overly complex and that language would seem simpler.)
Super interesting. Like I said, I have next to no practical experience with Java, and the Java ecosystem, so it looks like I misunderstood exactly what you meant. What you are describing is very cool. I guess you summed it up nicely when you said:
And that is a problem in the JavaScript universe, not only with build processes, but with pretty much every aspect of coding and development. It's the whole convention vs. configuration thing and in the JavaScript world, we are big time in the configuration side of things. There are so many ways to do everything. JavaScript fatigue is a real thing.
So you definitely have a point; you can't expect that running
npm buildon one JS project, will have the same impact as runningnpm buildon another JS project. There is no convention when it comes to that.