{"id":1482,"date":"2015-10-30T04:31:32","date_gmt":"2015-10-30T11:31:32","guid":{"rendered":"http:\/\/10kdev.net\/?p=1482"},"modified":"2015-10-30T11:29:32","modified_gmt":"2015-10-30T18:29:32","slug":"its-in-npm-somewhere-it-must-be","status":"publish","type":"post","link":"http:\/\/10kdev.net\/?p=1482","title":{"rendered":"It’s in npm somewhere<\/i> . . . it must be."},"content":{"rendered":"
\"\"<\/a>

“Package versions? As many as there are stars in the sky.” – Dances with Dependencies<\/p><\/div>\n

I’m sure many developers have been finding nodejs buried in pretty much everything these days, and that can mean dependency management with npm and package.json. \u00a0And more often than not I am finding version collisions and dependency needs unmet in non-trivial and time draining situations.<\/p>\n

Working on a large commerce engine, it fell to my shoulders to do a minor version upgrade<\/strong>.<\/p>\n

Versioning on some<\/em>\u00a0pieces have been very discrete: JDK7 (for now), Ruby 2.2.2; jstl 1.2 libraries and specific jdbc drivers. \u00a0The vendor \u00a0ignored specifying versions and “get the latest greatest” rules the roost for ruby gem packages and nodejs. \u00a0So far the who-cares-what-version gems have not been a problem (but \u00a0they *will* be, can almost guarantee it). \u00a0Other packages needed for node aren’t specified in package.json, allowing for the pull of the latest-greatest as well.<\/p>\n

I have a few setup tasks, then to run \u00a0npm install<\/strong> \u00a0in the project to pull the node modules, then do gradle build<\/strong>. \u00a0We can run it from there.<\/p>\n

First the vanilla try: I run npm install, then gradle build — breakage on the build:<\/p>\n

Running “sass:dev” (sass) task\u00a0>> (base: #CE1A2B, light: #e63546, dark: #a11422) isn’t a valid CSS value.<\/em><\/p>\n

Working with two other team members, I got a hint: we needed to specify a version, decided by magic (trial and error) in package.json, a dependency entry:<\/p>\n

\"node-sass\":\"3.2.0\"<\/pre>\n
That fixed some problems with our EXISTING builds; this breakage was intermittent and now in hindsight I am guessing due to a race condition of node-sass dependency pulls; get lucky and the right version wins. \u00a0We propagate the fix to the repository.<\/p>\n
But for the minor version upgrade I was working on? \u00a0Didn’t work. \u00a0Running npm install\u00a0would generate an error:<\/p>\n
Cannot download “https:\/\/github.com\/sass\/node-sass\/releases\/download\/v3.2.0\/win32-x64-46_binding.node”<\/em><\/p>\n
Digging through github to see their releases, well,\u00a0there is no minor version of -46 for node-sass 3.2.0<\/a>. \u00a0The newest version being 3.4.1 right now — but that version (pulling latest-greatest method, our initial methodology problem) which has a -46 breaks the build due to the css error mentioned above. \u00a0Another very strange thing is that no matter what version I put in, it asks for the -46 rendition; as if when I specify a version in package.json it only parses teh x.x.x part, but doesn’t allow for me to specify the -xx version part.<\/p>\n
Running\u00a0npm install –dev<\/strong>\u00a0 was a huge mistake as it pulled the universe down and still broke; \u00a0when I went to delete the node_modules directory there were really long file paths that Windows hates to delete. \u00a0I had to rename tons of recursive folders to “a”. \u00a0Cost me at least an hour to bail out of that route.<\/p>\n
So I started to climb through the repository for node-sass up from 3.2.0, and found\u00a0a 46 release for version 3.3.3. \u00a0I tried that, and it worked and built. \u00a0I don’t know why, I can’t generate a legible dependency tree or run a dry run with npm-install.<\/p>\n
It’s disconcerting though — why 3.3.3 other than it has a -46 rendition? \u00a0There’s no vendor explanation. And only a long regression test will say if it really works. \u00a0I talked with the local nodejs expert and asked questions about the type of dry-run I’d like to do with npm (from what I understand, and how to get a dependency graph and figure out what version I need — this is the next step to line up with the regression tests.<\/p>\n
Specifying package versions seem to have a shortcoming, in my opinion, as well. \u00a0 This article from nodejitsu does a great job at discussing semantic package naming<\/a>, but there doesn’t seem to be a way to specify my -46 release and the article kind of confirms that (I tried every syntax under the sun). \u00a0Here is the syntax for\u00a0package.json<\/a>, my situation concerned with dependencies, \u00a0and I tried different things without success. \u00a0For instance specifying “~3.2.1” which is an approximate-equivalent provided a successful npm install, but not a successful gradle build.<\/p>\n
The npm system isn’t quite as mature as say maven but it is making leaps because people like you and I are coming in with experience on different systems and use cases to contribute. \u00a0For now though, I have to dig down into the dependency graphs even further, and better yet, ask the vendor to list versions of packages it needs for its software instead of assuming the latest-greatest will always work.<\/p>\n","protected":false},"excerpt":{"rendered":"
I’m sure many developers have been finding nodejs buried in pretty much everything these days, and that can mean dependency management with npm and package.json. \u00a0And more often than not I am finding version collisions and dependency needs unmet in non-trivial and time draining situations. Working on a large commerce engine, it fell to my […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[69,82],"tags":[85],"_links":{"self":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/1482"}],"collection":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1482"}],"version-history":[{"count":11,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/1482\/revisions"}],"predecessor-version":[{"id":1493,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/1482\/revisions\/1493"}],"wp:attachment":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1482"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1482"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1482"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}