In the above incident, we dug down, and found that graphql-tools/schema had released a patch version which added a dependency on a new package value-or-promise. Gatsby! Specifically, when we looked at the package.json for gatsby-recipes, we found this: "dependencies": "^7.0.0", "^15.1.1", Even if you choose to use exact versions in your package.json, you are still impacted by this behavior, as your dependencies almost certainly use version ranges, and the exact version of your transitive dependencies will be ambiguous.Īs we discovered during our investigation, a classic example is. You run the risk of pulling in new versions of dependencies without warning and at any time. While this is great for keeping your dependencies up-to-date, if handled incorrectly, it can lead to builds that are not reproducible over time.
This is so common that the ^ x.y.z is actually the default dependency added to your package.json when you run npm install -save package. For example, ^1.0.0 means "1.0.0 or any later minor version" (e.g. In the npm world, it is a common practice to allow ranges of dependencies. In semantic versioning, the version is specified as x.y.z, with x being the major version, y the minor version, and z the patch version. In npm, dependencies are specified using semantic versioning in a package.json file.
To solve the mystery, we first need some background on versioning in npm. No code had changed since the last build, and the open source and SDLC teams confirmed that the GPL policy had not changed either. They were not aware that they depended on smartwrap, and had never encountered a build failure for it before. While the dependency graph looks straightforward, teams were nevertheless mystified. Now, on to the build failures! Below is the dependency graph we found when debugging the issue earlier this year. This deeply nested GPL dependency was identified during the build, and prevented the dependent products from being built.
Many companies do not permit using GPL dependencies in internally developed software due to the logistical complexity of ensuring that all the derivative source code is promptly open sourced under a GPL compatible license.
By contrast, copyleft licenses, such as GPL, require "derivative" software to distribute its source code to its users (e.g. Permissive open source licenses, like Apache 2.0 and MIT, allow use of the open source software with very few obligations.
:) ) Broadly speaking, there are two categories of open source licenses: permissive and copyleft. (If you have a real-life legal question, seek answers from a lawyer, not a blog post. The second clue: an error message that states that smartwrap-1.2.5 is unavailable for download due to a GPL 2.0 license.ĭespite all these clues, mysteries linger: What is smartwrap, and why are we depending on it? Why did the build suddenly fail now, when it succeeded an hour ago? How could we fix this before today's release? What is GPL, and why are the artifacts licensed under this license not permitted for use?įirst - a note on GPL that is a simplification, but will suffice for this blog post. The first clue: all these teams use GatsbyJS, an open source JavaScript framework. Several teams are reporting sudden unexpected JavaScript build failures.