Meteor Hang-up: Extracting Package….

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/build code/tools location. I relocated 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 of 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 awhile (upward of 30+ minutes) so expect to wait awhile to know if it fails.

Thankful for Integrated Terminals in Visual Studio Code

Since before I started my software development career, I have been using Visual Studio. It is a beast-mode IDE with tons of heavy-weight features and a bountiful supply of extensions. Don’t get me wrong, Visual Studio is near and dear. It has been the key to successful delivery of many kinds of projects. Since Visual Studio was so useful, I honestly wondered why Visual Studio Code was even created. After using it though, my thoughts changed from “why?” to “this is amazing!”

To be able to view everything on a single screen is hard to do – some would say unnecessary or even Noise. One of the great thing about VS Code is that it accomplishes the two feats of allowing a developer to quickly discover what they need during development without needing to wade through the noise. This is done by a simple tab-like interface including Explorer, Search, Git, Debug, and Extensions. The best part about this is the Integrated Terminal. It is very simple to get started, easily accessible, and easily ignored.

Integrated Terminals

vscintegratedterminal

My primary use for VS Code is front-end development. VS Code offers great tooling for creating high-quality user interfaces using the latest frameworks such as Angular 2 and React. Full-stack development can be done at once with a single language (JavaScript). With Integrated Terminals, Node.js operations can be performed quickly and easily.

With Extensions offering further integration, I find VS Code especially useful when developing with Node. Its Integrated Terminals allow an easy way of managing Node operations. When developing a MEAN stack application, each tier can get its own terminal for operations specific to that tier.

Dedicated terminals per tier is also beneficial because certain operations are long-running such as running MongoDB, Node and Angular. I tend to create a terminal per long-running operation. VSC makes it very easy to get these started – and to ignore them when they are not appropriate for the current task. For example, I can ignore the DB and Services when styling an Angular 2 component while still maintaining the benefit of them running so I can quickly test my work.

When writing front-end code, I would definitely consider Visual Studio Code.

Commands

  • Ctrl+`
    • Toggle Integrated Terminal Panel
  • Ctrl+Shift+`
    • Create New Integrated Terminal Instance
  • Ctrl+Shift+P
    • Begin searching the Command Palette

User Interface

vscintegratedterminalpane

Interact with Integrated Terminals like you would a Command Prompt. Multiple instances can be created while being accessible by simply making a selection from the drop-down. From the small toolbar, instances can be removed, more instances can be created, and the down-arrow closes the entire panel.

and to close,

Angular 2 in the MEAN Stack – A Project Template

I recently became aware of the beauty of developing with the MEAN stack. It started with my desire to brush up on Angular 2 and using the Angular CLI. I ended up with a TODO application that runs on Node using MongoDB, Express.js, and Angular 2 (from a foundation found here: https://scotch.io/tutorials/mean-app-with-angular-2-and-the-angular-cli).

I am also a fan of LESS. It makes writing modular CSS a breeze. I am also not yet sold on the Styled Component approach Angular is now pushing. I do believe Component-based UI architectures make writing modular CSS quite simple. I just don’t think styles should be located across the application when, with an optimally modular UI, the CSS used can be quite minimal. Beyond that, an application should have a look and feel that gives the user at least the illusion of cohesiveness. Easily done when styles are in one place.

Using Feature Modules with Angular 2 makes a lot of sense. Each feature can be created in isolation while still being integrated with the rest of the application. The module structure of the TODO application is shown in Figure 1. This structure allows the application to be extended and makes features easy to find for updates and bug fixes. The approach also provides a more SOLID application.

todofeaturemodule
Figure 1: Module structure

With the focus on Angular 2, the server-side code is quite minimal and I don’t have much to say about it. Figure 2 depicts the main ideas.

todoapi
Figure 2: Server-side

I almost forgot to mention that this app is on GitHub: https://github.com/calebmagenic/ng2-mean. Let me know your thoughts!

I look forward to continuing my work with the MEAN stack and sharing what I find that works – and what doesn’t work so well. Look for more in the future.