loading...

re: Node.js has a higher cognitive load than Java VIEW POST

TOP OF THREAD FULL DISCUSSION
re: There are many ways to achieve this, and it does involve some initial work on the part of the developer, but once everything is setup, it is a thin...

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.

Code of Conduct Report abuse