Updated sourcecred dependencies and node version

A fairly technical #didathing: over the past few days, I’ve updated almost all of SourceCred’s dependencies. I also enabled Greenkeeper, so that our deps will now get updated automatically.

Dependency upgrades are one of those things where the longer you wait, the more gnarly they become. At this point, many of the deps were months out of date, so the process was somewhat gnarly – but less gnarly than it would have been if we’d waited another half a year. :slight_smile:

Once all the dependencies were up-to-date, I focused on adding full SourceCred support for node 10 and node 12. Prior to this work, yarn test --full only passed for node 8. Node 8 is pretty old (it goes out of LTS at the end of the year) and many new contributors arrive with a newer version of node. So, it’s just good form to ensure we support new versions of node.

However, supporting node 10 and above proved pretty tricky. The issue was that the test failure on recent nodes was weird. First, some context: we have a script build_static_site.sh which is responsible for producing statically-servable versions of SourceCred. This is how we produce the website over at sourcecred.io. Since it’s a vital piece of infrastructure, we also have sharness tests for it. One of those tests needs to verify that the site is being built with the right repositories loaded. The repositories are provided via an environment variable, and to test it, we have a fairly hacky approach: when the SourceCred server starts, it logs that environment variable to console so that the test can grep for it and ensure it was set properly.

That all worked fine in node 8. However, in node 10 and above, the test failed… because the server never logged anything. The code ran as expected, but the console.log statement had no side effect. I did some experimenting, and concluded that it had to do with the static-site-generator-webpack-plugin which we depended on. With some more experimentation, I created a minimal reproduction of the issue using that plugin, and then started to dive into the code for the plugin itself. (One of the wonderful things about open-source is that you can always dive into bugs to try to understand them, and perhaps fix them, yourself.) Fortunately, the plugin was only around 200 lines of code. It depended on a little-known npm package called eval to run the server script… and it was eval’s behavior that changed between node 8 and node 10. The root issue was that eval used Object.keys(global) to find the global properties (e.g. console) to provide to evaluated scripts. However, node 10 made console non-enumerable. And that meant that on node 10 and above, eval'd scripts could no longer use console.log.

I sent off a fix to eval and the maintainer swiftly merged it and re-released it. (Open-source happy times yet again!) Once the fix was available, I updated our lockfile to ensure that we’d always use the version of eval that works properly. And with that, the last barrier to using node 10 and node 12 with SourceCred was gone!

2 Likes