DEV Community

loading...

Discussion on: Node.js has a higher cognitive load than Java

snowfrogdev profile image
Philippe Vaillancourt

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 thing of pure beauty. I'll give you an example of the build process for a small framework I'm working on, it might not touch on all the points you mention, but it should be enough to make you a (at least partial) believer. If you want to take a deeper look, check it out here.

So, with one command, git push here is what happens:

  • Runs all unit tests using jest
  • Transpiles TypeScript to JavaScript
  • Bundles up the code using rollup
  • Automatically generates API documentation using ts-doc
  • Pushes commits to the remote (github)
  • Starts up a build on Travis CI where it will:
    • Install all dependencies
    • Run all unit tests
    • Transpile TypeScript to JavaScript
    • Bundle up the code using rollup
    • Automatically generate API documentation using ts-doc
    • Send test coverage info to coveralls
    • Push API documentation to GitHub pages
    • Analyze the commits to see if there are changes that warrant a patch, minor or major version release.
    • If there is, modify package.json file to include new version number.
    • Push new release to NPM
    • Add release information to CHANGELOG.md
    • Commit the new package.json and CHANGELOG.md to GitHub remote.

Of course, your build process would not need many of these steps and would add some that aren't there. But the point is that, with one command, all these automated steps were triggered and you can make that happen too.

How? It all depends on the tools, libraries, services and environments that you use. But the basis for all this is NPM scripts, that you'll normally find in the package.json file. You might have to write a few custom Node scripts to do some fancier stuff but it's not all that complicated and is well worth it to automate the entire process. Hope this helps.

Thread Thread
grahamcox82 profile image
Graham Cox Author

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.)

Thread Thread
snowfrogdev profile image
Philippe Vaillancourt

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.