- Nodemon Stuck At Waiting For Localhost Macos Free
- Nodemon Stuck At Waiting For Localhost Macos 7
- Nodemon Stuck At Waiting For Localhost Macos 2
Node.js is an open-source, cross-platform, JavaScript runtime platform that enables JavaScript for server-side scripting to produce dynamic web pages before sending it to the client’s web browser. Node.js is built on Chrome’s V8 JavaScript engine. Node.js allows the creation of Web servers and networking tools using JavaScript. It also creates a collection of “modules” that handle various core functionalities like file system I/O, networking (DNS, HTTP, TCP, TLS/SSL, or UDP), binary data (buffers), cryptography functions, data streams, and other core functions.
$ yarn add nodemon -dev # or, using npm: $ npm install nodemon -save-dev As you can see, when doing a local install, we can install as a dev dependency. Note also that with a local install you won’t be able to use the nodemon command directly from the command line, but instead you can use it as part of some npm scripts, or with npx. The pickle in this case is that if another user has connected to the queues automatically published by Bob’s computer, any job sent to this rogue queue recieves “Hold for Authentication” on their macOS device or “Incorrect name or password on their iOS device. Jul 22, 2016 I have used nodemon a lot, it was my solution for a long time to not manually restart my node.js project. Then webpack appeared and along with that webpack-dev-server which automatically reloads the page when a change happens. That works perfectly when you are developing a pure client-side app. Along comes isomorphic, no sorry, universal app.
Read this =>How to Install Homebrew on macOS
This tutorial will help you to install Node.js and NPM on MacOS operating system using the Homebrew package manager.
Prerequisites
Before starting the installation of Node.js and NPM using this tutorial you must have the following prerequisites
- Terminal: You must have Mac Terminal access and little knowledge about working with the terminal application. Ao login to your Mac system and open terminal
- Homebrew: Homebrew is a popular package manager for the Mac operating systems. It is useful for installing most open source sofware like Node
Install Node.js on MacOS
Let’s start the installation of Node.js on your Mac system using Homebrew. So first update the Homebrew package manager index. Then you can install Node.js package in your MacOS system using the following command:
You have successfully installed Node.js on your system. The default Node.js will be installed under the /usr/local/Cellar/node directory on your system. Now check and verify the installed version of Node.js, Execute below command on terminal. This will show you the installed version info.
Also, find the installed version of NPM installed with Node.js. NPM is used for managing modules of Node.js on your system.
The above output shows that you have installed Node.js version 12.4.0 and NPM 6.9.0 on your macOS system.
Upgrade Node.js on macOS
The newer versions of Node.js releases very frequently. You can use Homebrew to update Node on your system. Just execute below commands to update the Homebrew index and then update Node.js.
Uninstall Node.js on macOS
You can simply use the Homebrew package manager to uninstall Node packages from your system. Just execute below command from the terminal.
Table of Contents
- 1 Not using development tools
Introduction
Node.js has seen an important growth in the past years, with big companies such as Walmart or PayPal adopting it. More and more people are picking up Node and publishing modules to NPM at such a pace that exceeds other languages. However, the Node philosophy can take a bit to get used to, especially if you have switched from another language.
In this article we will talk about the most common mistakes Node developers make and how to avoid them.You can find the source code for the examples on github.
1 Not using development tools
- nodemon or supervisor for automatic restart
- In-browser live reload (reload after static files and/or views change)
Unlike other languages such as PHP or Ruby, Node requires a restart when you make changes to the source code.Another thing that can slow you down while creating web applications is refreshing the browser when the static code changes. While you can do these things manually, there are better solutions out there.
1.1 Automating restarts
Most of us are probably used to saving a file in the editor, hit [CTRL+C] to stop the application and then restart it by pressing the [UP] arrow and [Enter]. However you can automate this repetitive task and make your development process easier by using existing tools such as:
What these modules do is to watch for file changes and restart the server for you. Let us take nodemon for example. First you install it globally:
Then you should simply swap the
node
command for the nodemon
command:Among the existing options for
nodemon
or node-supervisor
, probably the most popular one is to ignore specific files or folders.1.2 Automatic browser refresh
Besides reloading the Node application when the source code changes, you can also speed up development for web applications. Instead of manually triggering the page refresh in the browser, we can automate this as well using tools such as livereload.
They work similarly to the ones presented before, because they watch for file changes in certain folders and trigger a browser refresh in this case (instead of a server restart). The refresh is done either by a script injected in the page or by a browser plugin.
Instead of showing you how to use livereload, this time we will create a similar tool ourselves with Node.It will do the following:
- Watch for file changes in a folder;
- Send a message to all connected clients using server-sent events; and
- Trigger the page reload.
First we should install the NPM dependencies needed for the project:
- express - for creating the sample web application
- watch - to watch for file changes
- sendevent - server-sent events, SSE (an alternative would have been websockets)
- uglify-js - for minifying the client-side JavaScript files
- ejs - view templates
Next we will create a simple Express server that renders a
home
view on the front page:Since we are using Express we will also create the browser-refresh tool as an Express middleware. The middleware will attach the SSE endpoint and will also create a view helper for the client script.The arguments for the middleware function will be the Express
app
and the folder to be monitored.Since we know that, we can already add the following lines before the view setup (inside server.js):We are watching the /views folder for changes. And now for the middleware:
As you might have noticed, if the environment isn't set to 'development' the middleware won't do anything.This means we won't have to remove it for production.
The frontend JS file is pretty simple, it will just listen to the SSE messages and reload the page when needed:
The eventsource-polyfill.js is Remy Sharp's polyfill for SSE. Last but not least, the only thing left to do is to include the frontend generated script into the page (
/views/home.html
) using the view helper:Now every time you make a change to the home.html page the browser will automatically reload the home page of the server for you (
http://localhost:1337/
).2 Blocking the event loop
Since Node.js runs on a single thread, everything that will block the event loop will block everything.That means that if you have a web server with a thousand connected clients and you happen to block the event loop, every client will just...wait.
Here are some examples on how you might do that (maybe unknowingly):
- Parsing a big json payload with the JSON.parse function;
- Trying to do syntax highlighting on a big file on the backend (with something like Ace or highlight.js); or
- Parsing a big output in one go (such as the output of a
git log
command from a child process).
The thing is that you may do these things unknowingly, because parsing a 15 Mb output doesn't come up that often, right? It's enough for an attacker to catch you off-guard and your entire server will be DDOS-ed.
Luckily you can monitor the event loop delay to detect anomalies. This can be achieve either via proprietary solutions such as StrongOps or by using open-source modules such as blocked.
The idea behind these tools is to accurately track the time spend between an interval repeatedly and report it. The time difference is calculated by getting the time at moment A and moment B, subtracting the time at moment A from moment B and also subtracting the time interval.
Below there's an example on how to achieve that. It does the following:
- Retrieve the high-resolution time between the current time and the time passed as a param;
- Determines the delay of the event loop at regular intervals;
- Displays the delay in green or red, in case it exceeds the threshold; then
- To see it in action, each 300 miliseconds a heavy computation is executed.
The source code for the example is the following:
You must install the chalk before running it. After running the example you should see the following output in the terminal:
As said before, existing open source modules are doing it similarly so use them with confidence:
If you couple this technique with profiling, you can determine exactly which part of your code caused the delay.
3 Executing a callback multiple times
How many times have you saved a file and reloaded your Node web app only to see it crash really fast? The most likely scenario is that you executed the callback twice, meaning you forgot to return after the first time.
Let's create an example to replicate this situation. We will create a simple proxy server with some basic validation. To use it install the
request
dependency, run the example and open (for instance) http://localhost:1337/?url=http://www.google.com/.The source code for our example is the following:The source code above contains almost everything except the proxying itself, because I want you to take a closer look at it:
In the callback we have handled the error condition, but forgot to stop the execution flow after calling the
respond
function. That means that if we enter a domain that doesn't host a website, the respond
function will be called twice and we will get the following message in the terminal:4 The Christmas tree of callbacks (Callback Hell)
Every time somebody wants to bash Node they come up with the 'callback hell' argument. Some of them see callback nesting as unavoidable, but that is simply untrue. There are a number of solutions out there to keep your code nice and tidy, such as:
- Using control flow modules (such as async);
- Promises; and
- Generators.
We are going to create a sample application and then refactor it to use the async module. The app will act as a naive frontend resource analyzer which does the following:
- Checks how many scripts / stylesheets / images are in the HTML code;
- Outputs the their total number to the terminal;
- Checks the content-length of each resource; then
- Puts the total length of the resources to the terminal.
Besides the async module, we will be using the following npm modules:
- request for getting the page data (body, headers, etc).
- cheerio as jQuery on the backend (DOM element selector).
- once to make sure our callback is executed once.
This doesn't look that horrible, but you can go even deeper with nested callbacks. From our previous example you can recognize the Christmas tree at the bottom, where you see indentation like this:
To run the app type the following into the command line:
After a bit of refactoring using async our code might look like the following:
5 Creating big monolithic applications
Developers new to Node come with mindsets from different languages and they tend to do things differently.For example including everything into a single file, not breaking things into their own modules and publishing to NPM, etc.
Take our previous example for instance. We have pushed everything into a single file, making it hard to test and read the code. But no worries, with a bit of refactoring we can make it much nicer and more modular. This will also help with 'callback hell' in case you were wondering.
If we extract the URL validator, the response handler, the request functionality and the resource processor into their own files our main one will look like so:
The request functionality might look like this:
Note: you can check the full example in the github repo.
Now things are simpler, way easier to read and we can start writing tests for our app. We can go on with the refactoring and extract the response length functionality into its own module as well.
The good thing about Node is that it encourages you to write tiny modules and publish them to NPM. You will find modules for all kinds of things such as generating a random number between an interval. You should strive for modularity in your Node applications and keeping things as simple as possible.
An interesting article on how to write modules is the one from substack.
6 Poor logging
Many Node tutorials show you a small example that contains
console.log
here and there, so some developers are left with the impression that that's how they should implement logging in their application.You should use something better than
console.log
when coding Node apps, and here's why:Nodemon Stuck At Waiting For Localhost Macos Free
- No need to use
util.inspect
for large, complex objects; - Built-in serializers for things like errors, request and response objects;
- Support multiple sources for controlling where the logs go;
- Automatic inclusion of hostname, process id, application name;
- Supports multiple levels of logging (debug, info, error, fatal etc);
- Advanced functionality such as log file rotation, etc.
You can get all of those for free when using a production-ready logging module such as bunyan. On top of that you also get a handy CLI tool for development if you install the module globally.
Let's take a look at one of their examples on how to use it:
If you run the example in the terminal you will see something like the following:
But in development it's better to use the CLI tool like in the screenshot:
As you can see, bunyan gives you a lot of useful information about the current process, which is vital into production. Another handy feature is that you can pipe the logs into a stream (or multiple streams).
7 No tests
We should never consider our applications 'done' if we didn't write any tests for them. There's really no excuse for that, considering how many existing tools we have for that:
- Testing frameworks: mocha, jasmine, tape and many other
- Assertion modules: chai, should.js
- Modules for mocks, spies, stubs or fake timers such as sinon
- Code coverage tools: istanbul, blanket
The convention for NPM modules is that you specify a test command in your
package.json
, for example:Then the tests can be run with
npm test
, no matter of the testing framework used.Another thing you should consider for your projects is to enforce having all your tests pass before committing. Fortunately it is as simple as doing
npm i pre-commit --save-dev
.You can also decide to enforce a certain code coverage level and deny commits that don't adhere to that level. The
pre-commit
module simply runs npm test
automatically for you as a pre-commit hook.![For For](https://user-images.githubusercontent.com/33719556/79960247-ce5d2280-84a2-11ea-8714-be2c260d6bc2.jpg)
In case you are not sure how to get started with writing tests you can either find tutorials online or browse popular Node projects on Github, such as the following:
8 Not using static analysis tools
Instead of spotting problems in production it's better to catch them right away in development by using static analysis tools.
Tools such as ESLint help solve a huge array of problems, such as:
- Possible errors, for example: disallow assignment in conditional expressions, disallow the use of
debugger
. - Enforcing best practices, for example: disallow declaring the same variable more then once, disallow use of
arguments.callee
. - Finding potential security issues, such as the use of
eval()
or unsafe regular expressions. - Detecting possible performance problems.
- Enforcing a consistent style guide.
For a more complete set of rules checkout the ESLint rules documentation page. You should also read the configuration documents if you want to setup ESLint for your project.
In case you were wondering where you can find a sample configuration file for ESLint, the Esprima project has one.
There are other similar linting tools out there such as JSLint or JSHint.
In case you want to parse the AST (abstract source tree) and create a static analysis tool by yourself, consider Esprima or Acorn.
9 Zero monitoring or profiling
Not monitoring or profiling a Node applications leaves you in the dark. You are not aware of vital things such as event loop delay, CPU load, system load or memory usage.
Nodemon Stuck At Waiting For Localhost Macos 7
There are proprietary services that care of these things for you, such as the ones from New Relic, StrongLoop or Concurix, AppDynamics.
You can also achieve that by yourself with open source modules such as look or by gluing different NPM modules. Whatever you choose make sure you are always aware of the status of your application at all times, unless you want to receive weird phone calls at night.
10 Debugging with console.log
When something goes bad it's easy to just insert
console.log
in some places and debug. After you figure out the problem you remove the console.log
debugging leftovers and go on.The problem is that the next developer (or even you) might come along and repeat the process. That's why module like debug exist. Instead of inserting and deleting
console.log
you can replace it with the debug
function and just leave it there.Once the next guy tries to figure out the problem they just start the application using the
DEBUG
environment variable.This tiny module has its benefits:
Nodemon Stuck At Waiting For Localhost Macos 2
- Unless you start the app using the DEBUG environment variable nothing is displayed to the console.
- You can selectively debug portions of your code (even with wildcards).
- The output is beautifully colored into your terminal.
Let's take a look at their official example:
If we run the example with
node app.js
nothing happens, but if we include the DEBUG flag voila: Besides your applications, you can also use it for tiny modules published to NPM. Unlike a more complex logger it only does the debugging job and it does it well.