In the world of Node.js and NPM, things can change at an increasingly rapid pace. This causes pain when starting or upgrading projects that require NPM packages. While there are sites like Greenkeeper, I see them as symptoms of a flawed system. Yes, I will say that without offering alternative solutions because at the moment I am aware of exactly zero. Suggestions welcome!
It is a wonderful world of possibility.
Complaining about NPM is not the point of this article. I’ll stop wasting time:
Recently I came across a few excellent tutorials about using Meteor, Ionic 2, Angular and React. They eventually brought me to Telescope Nova. My first thought was: this looks promising.
After forking and cloning and other Gitisms, I was ready to start the application:
npm install npm run start
Of course, I have a Microsoft development background so when I saw a bunch of red because of ‘.sh’ I wondered why these two letters were such a problem. I ended up having to update my start script to exclude this bit of code. The script I excluded simply renames a sample_settings.json file to settings.json. I figured that was a safe thing to shortcut in this case by renaming it myself.
My next step was to try it again!
> Nova@1.0.0 start C:\Demo\Telescope > meteor --settings settings.json [[[[[ C:\Demo\Telescope ]]]]] => Started proxy. => Started MongoDB. => Extracting std:account-ui@1.2.17
To be honest, I let it try for a few hours and it just could not get that pesky package extracted. Certainly, something had gone wrong before that. After digging into the depths of Nova, Meteor, and NPM, I finally explicitly searched within Stack Overflow for Extracting std:accounts-ui.
The search came up with only 2 results which are both linked at the bottom of this article. Most importantly: following the suggestions solved my problem.
I fixed the issue by relocating the 7z executable (7z.exe) from: C:\Users\[UserName]\AppData\Local\.meteor\packages\meteor-tool\1.4.2_3\mt-os.windows.x86_32\dev_bundle\bin to a place outside of any source code, build code, and tool locations. I relocated it and instead of removing it because I didn’t want to mess up my machine any more than it already may have been. Turns out, the missing 7z.exe was all it took to get my Meteor package installed properly!
It figures that the solution was to create a sort of FileNotFound scenario.
In an effort to spread the word, the following links lead me to this solution:
http://stackoverflow.com/questions/41155583/meteor-1-4-2-3-adding-package-extracts-forever-windows
http://stackoverflow.com/questions/41195227/meteor-package-extracting-forever
https://github.com/studiointeract/accounts-ui/issues/67
https://github.com/meteor/meteor/issues/7688
I hope this helps. It is a rather simple solution in the end. I am very interested in learning about your past issues with our current favorite packaging system and its various dependencies. Feel free to comment if you have hard-fought wisdom to share!
UPDATE: Just a quick update here, turns out this approach can be helpful when updating packages or if you get stuck here ‘Extracting meteor-tool@1.4.2_5’ (after the recent patch). Note: extracting meteor tools can take a while (upward of 30+ minutes) so expect to wait a bit to know if it fails.