How I accidentally contributed to an open-source project

Latest node.js patch that broke an CLI project.

How I accidentally contributed to an open-source project

Photo by Marc St on Unsplash

I can’t do my job

One morning, my local environment stopped working. The command to run and build an Aurelia project, a frontend web framework, mysteriously failed with the following message:

error: Error: spawn EINVAL
  at ChildProcess.spawn (node:internal/child_process:421:11)
  at spawn (node:child_process:761:9)
  ...

Since none of the typical solutions (reinstalling dependencies or reverting back recent changes) worked, I was left to explore the internet.

Eventually, I came across a discussion forum from an open-source project: Node-RED — low-code development tool for visual programming. Their maintainers had come across the same error message and they found that a security release from Node.js was the root cause.

Node.js codebase included a method in which “a malicious command line argument can inject arbitrary commands and achieve code execution even if the shell option is not enabled.” This impacted all Windows users in active release lines of 18.x, 20.x, and 21.x.

Here comes the mystery. This means that my machine had magically upgrade the Node.js version installing this latest change. Since I am on Windows 11 using their latest 21.7.3, this had to be the issue.

Node-RED maintainers were able to resolve this issue quickly by adding an option property of shell: true to the spawn() constructor argument.

The CLI repository

Looking at the Aurelia's CLI project on GitHub, I found a line referencing the exact spawn method without the shell option set.

Now, here is the problem. Aurelia’s CLI package has not been updated in 6 months. Aurelia has since moved to completely rewrite the project: Aurelia v2. I had little hope that this issue will be detected let alone resolved in the near future.

Sacrifice

Solutions (in order from worst to best)

Stop using Windows

This is not an option since I work for an organization with 99% of developers using Windows. However, good news is that our servers are all Linux; therefore, this error is only thrown during local development.

Downgrade Node.js

Downgrading the Node.js version to the latest LTS release will solve the problem (for now). Our local machines will start working and we can finally get back to work. However, this felt wrong as it seemed like I was the first to find the problem, so I needed a way to let the world know.

Contribute to the open-source project

Since no one has yet reported this issue on their GitHub issues page, I opened a new thread explaining the issue I was having as well as the solution.

That day however, the maintainer of the project responded with the following message:

Thx! Do you mind to try the fix and send a PR?

I’ve never contributed or even attempted to contribute to an open-source project. This was also an CLI project which I don’t have experience working on. Not only that, the project has over 400 stars and 5,000 weekly downloads on npm.

It was a lot of pressure. I hesitated to respond back. I had no idea where to even begin. That is until my manager encourage me to just try. So I did. And I succeeded.

I merged a code change requested by the maintener, and the package was released to npm a few days later. Installing the new version on my machine, our project started working again.

This has been a humbling experience learning the side of technology that I've never looked, as well as eye opening to the possibility of how I can continue to contribute to the open-source community.

P.S.

To this day, I’m still not certain on what caused the Node.js version on my machine to auto update to latest. My speculation is Chocolatey, which is optionally installed upon Node.js installation process. I now have an approach to managing the versions intentionally:

  • Decide on an LTS release to use everywhere (local and servers).

  • Match your machine’s version with the production server.

  • Subscribe to the Node.js blog and manually install any new releases to test your local environment. After confirming, downgrade to the LTS version. If the latest version fails one of your tools, search the repository online (typically on GitHub) and report the issue if there isn't one already.

  • Manage these versions using nvm.