Posted in Node Dot JS | Leave a comment

Right Click And Display Menu

handleClick(e) {
console.log(e.nativeEvent.which); // type: left, value – 1
console.log(e.nativeEvent.which); // type: right, value – 3
console.log(e.type); // type: left, value – click
console.log(e.type); // type: right, value – contextmenu
Posted in Node Dot JS | Leave a comment

Mocha Testing

process.env.NODE_ENV = 'test';

let mongoose = require("mongoose");
let Book = require('../app/models/book');

let chai = require('chai');
let chaiHttp = require('chai-http');
let server = require('../server');
let should = chai.should();


describe('Books', () => {
    beforeEach((done) => {
        Book.remove({}, (err) => { 
  describe('/GET book', () => {
      it('it should GET all the books', (done) => {
            .end((err, res) => {
  * Test the /POST route
  describe('/POST book', () => {
      it('it should not POST a book without pages field', (done) => {
        let book = {
            title: "The Lord of the Rings",
            author: "J.R.R. Tolkien",
            year: 1954
            .end((err, res) => {

Posted in Uncategorized | Leave a comment

Type Script Project Setting up

TypeScript has had first class support for Node.js since inception. Here’s how to setup a quick Node.js project:

Note: many of these steps are actually just common practice Node.js setup steps

  1. Setup a Node.js project package.json. Quick one : npm init -y
  2. Add TypeScript (npm install typescript --save-dev)
  3. Add node.d.ts (npm install @types/node --save-dev)
  4. Init a tsconfig.json for TypeScript options (node ./node_modules/typescript/lib/tsc --init)
  5. Make sure you have compilerOptions.module:commonjs in your tsconfig.json

That’s it! Fire up your IDE (e.g. alm -o) and play around. Now you can use all the built in node modules (e.g. import fs = require('fs');) with all the safety and developer ergonomics of TypeScript!


Bonus: Live compile + run

  • Add ts-node which we will use for live compile + run in node (npm install ts-node --save-dev)
  • Add nodemon which will invoke ts-node whenever a file is changed (npm install nodemon --save-dev)

Now just add a script target to your package.json based on your application entry e.g. assuming its index.ts:

  "scripts": {
    "start": "npm run build:live",
    "build:live": "nodemon --exec ./node_modules/.bin/ts-node -- ./index.ts"

So you can now run npm start and as you edit index.ts:

  • nodemon reruns its command (ts-node)
  • ts-node transpiles automatically picking up tsconfig.json and the installed typescript version,
  • ts-node runs the output javascript through Node.js.

Creating TypeScript node modules

Using modules written in TypeScript is super fun as you get great compile time safety and autocomplete (essentially executable documentation).

Creating a high quality TypeScript module is simple. Assume the following desired folder structure for your package:

├─ package.json
├─ tsconfig.json
├─ src
│  ├─ All your source files
│  ├─ index.ts
│  ├─ foo.ts
│  └─ ...
└─ lib
  ├─ All your compiled files
  ├─ index.d.ts
  ├─ index.js
  ├─ foo.d.ts
  ├─ foo.js
  └─ ...
  • In your tsconfig.json

    • have compilerOptions"outDir": "lib" and "declaration": true < This generates declaration and js files in the lib folder
    • have include: ["./src/**/*]" < This includes all the files from the src dir.
  • In your package.json have

    • "main": "lib/index" < This tells Node.js to load lib/index.js
    • "types": "lib/index" < This tells TypeScript to load lib/index.d.ts

Example package:

  • npm install typestyle for TypeStyle
  • Usage: import { style } from 'typestyle'; will be completely type safe.


  • If you package depends on other TypeScript authored packages, put them in dependencies/devDependencies/peerDependencies just like you would with raw JS packages.
  • If you package depends on other JavaScript authored packages and you want to use it type safely in your project, put their types e.g. @types/foo in devDependencies. JavaScript types should be managed out of bound from the main NPM streams. The JavaScript ecosystem breaks types without semantic versioning too commonly, so if your users need types for these they should install the @types/foo version that works for them.

Bonus points

Such NPM modules work just fine with browserify (using tsify) or webpack (using ts-loader).

Posted in Node Dot JS | Leave a comment


install stepstep1: npm install ts-nodestep2: create file name mocha.opts in root project folder with this code--require ts-node/register
--watch-extensions ts
step3: npm install --global mocha
step4:  npm install mocha –save-devstep5: add this content code to package.json"scripts": {
"test": "mocha --opts mocha.opts",
step6: npm install chai, npm install @types/chai ( code

// import { suite, test, slow, timeout } from “mocha-typescript”;
import assert from ‘assert’;
import ‘mocha’;
import {expect} from ‘chai’;
describe(‘my test’, () => {
it(‘does something’, () => {
note: mocha package contain functional (describe, it)
chai package contain functional expect


step1: npm i ts-node -D

step2: npm install --global mocha, and then install npm install @types/mocha

step3: npm install --global mocha

step4: npm instal mocha –save-dev

step5: npm instal mocha

Unit testing using Typescript and Mocha

How to setup testing using Typescript and Mocha

Not long ago I wrote a post on how to setup testing using Mocha, Chai, Karma, Webpack, Sinon and TypeScript and although this is something I still use today, using karma and Webpack might be an overkill scenario. Warning: if you are using Webpack to bundle other things such as CSS and/or SASS, for instance, this setup won’t work for you.

Why overkill you might ask? Well, if all you’re doing is writing some TypeScript and bundling it, you don’t need Webpack to load your modules, Node can do it. And you probably don’t need to load a browser, you might be writing code that is independent of the browser, or in your tests you might be using something such as jsdom.

The configuration is straightforward, but it might take some time to find that, so that’s why I’m writing this post.

First, to load tests written in TypeScript, we need to install ts-node.

npm i ts-node -D

Next, what I added to scripts to the package.json file.

  "scripts": {
    "test": "mocha --opts mocha.opts && rm -rf test",
    "test:auto": "mocha --opts mocha.opts --watch",
    "start": "webpack-dev-server"

In those scripts, the important part is that I’m telling mocha to look for its options in a mocha.opts file.

Here’s that file:

--require ts-node/register 
--reporter dot
--watch-extensions tsx,ts 

We have to tell mocha to require ts-node, I’m also changing the reporter, but that’s optional.

Next, I’m setting up mocha to watch for tsx and ts extension files, so that when those change it will rerun the tests. By default, it watches only js files.

Finally, by default mocha looks for tests in a test folder and only for .js files. I’m telling mocha to look for .spec.tsx and .spec.ts files inside the app directory and its subdirectories.

PS: As of Node.JS 6, Node’s support for ES6 features has increased a lot. That means that when writing TypeScript code, we can set the compiler to target ES6 safely.


Install with npm globally:

$ npm install --global mocha

or as a development dependency for your project:

$ npm instal mocha --save-dev

To install Mocha v3.0.0 or newer with npm, you will need npm v1.4.0 or newer. Additionally, to run Mocha, you will need Node.js v0.10 or newer.

Mocha can also be installed via Bower (bower install mocha), and is available at cdnjs.



Writing mocha tests with style – OOP style:

import { suite, test, slow, timeout } from “mocha-typescript”;
@suite class Hello {
    @test world() {
        assert.equal(1, 2, “Expected one to equal two.”);

The test UI will register a suite with tests for the @suite and @test decorators. When the tests run, the class will be instantiated once for each @test method and the method will be called.

Build Status


Test UI

The test interface provides support for mocha’s built-in tdd, bdd: describe/suite, it/test, timeout, slow, it.only and it.skip; as well as TypeScript decorators based test UI for classes. You can mix and match:

import { suite, test, slow, timeout } from “mocha-typescript”;
suite(“one”, () => {
    test(“test”, () => {});
@suite class Two {
    @test method() {}

Similarly you can use describe/it:

import { suite, test, slow, timeout } from “mocha-typescript”;
describe(“one”, () => {
    it(“test”, () => {});
@suite class Two {
    @test method() {}

Or even mix the two approaches to get nested suites:

import { suite, test, slow, timeout } from “mocha-typescript”;
describe(“suite one”, () => {
    it(“test one”, () => {});
    @suite class TestTwo {
        @test method() {}


The mocha-typescript comes with a watcher script that runs the TypeScript compiler in watch mode, and upon successful compilations runs the mocha tests, concatenating the output of both. This in combination with the support for “only”:

@suite class One {
    @test.only method1() {}
    @test mothod2() {}

Allows for rapid development of both new functionality and unit tests.

Please note, the built in mocha watcher should work with mocha-typescript UI and the awesome-typescript-loader.

Thanks to

  • Haringat for the async support in before and after methods.
  • godart for taking the extra step to support non-default test file paths.

Setting Up

Adding Mocha-TypeScript to Existing Project

If you already have an npm package with mocha testing integrated just install mocha-typescript:

npm i mocha-typescript –save-dev

Then require the mocha-typescript in your test files and you will be good to go:

import { suite, test, slow, timeout } from “mocha-typescript”;
@suite class Two {
    @test method() {}

Setting up New Project With Custom UI


Fork the mocha-typescript-seed repo, or clone it:

git clone

Don’t forget to edit the package.json, and check the license.

From that point on, you could:

npm i
npm test
npm run watch

Manual Steps

Create a folder, cd in the folder, npm init, npm install:

npm init
npm install mocha typescript mocha-typescript @types/mocha chai @types/chai source-map-support nyc --save-dev

Edit the package.json and set the scripts section to:

  "scripts": {
    "pretest": "tsc",
    "test": "nyc mocha",
    "watch": "mocha-typescript-watch",
    "prepare": "tsc"

You may omit the nyc tool and have "test": "mocha" instead, nyc is the instanbul code coverage reporting tool.

Add a tsconfig.json file with settings similar to:

    "compilerOptions": {
        "target": "es6",
        "module": "commonjs",
        "sourceMap": true,
        "experimentalDecorators": true,
        "lib": [ "es6" ]

Create test folder and add test/mocha.opts file.

--ui mocha-typescript
--require source-map-support/register
  • Sets the mocha-typescript as custom ui
  • Optionally require the source-map-support/register to have typescript stack traces for Errors
  • Optionally provide test files list, point to specific dist fodler, or skip this to use mocha’s defaults Add your first test file test/test.ts:
// Reference mocha-typescript's global definitions:
/// <reference path="../node_modules/mocha-typescript/globals.d.ts" />

@suite(timeout(3000), slow(1000))
class Hello {
    @test world() {

From that point on, you could either:

npm test
npm run watch

To run the tests once manually or run all tests. Keep in mind you can use add .only to run a single test.

Setting Up Dev Test Watcher

There is a watcher script in the package, that runs tsc -w process and watches its output for successful compilation, upon compilation runs a mocha process.

You will need a tsconfig.json, and at least test.ts mocha entrypoint.

Install mochatypescript and mocha-typescript as dev dependencies (required):

npm install mocha typescript mocha-typescript --save-dev

Add the following npm script to package.json:

    dev-test-watch: mocha-typescript-watch

And run the typescript mocha watcher from the terminal using npm run dev-test-watch.

You can use the watcher with plain describeit functions. The decorator based interface is not required for use with the watcher.

The mocha-typescript-watch script is designed as a command line tool. You can provide the arguments in the package.json’s script. In case you are not using the default test.js file as entrypoint for mocha, you can list the test suite files as arguments to mocha-typescript-watch and they will be passed to mocha. For example:

    dev-test-watch: mocha-typescript-watch -p tsconfig.test.json -o mocha.opts dist/test1.js dist/test2.js

For complete list with check ./node_modules/.bin/mocha-typescript-watch --help:

  -p, --project  Path to tsconfig file or directory containing tsconfig, passed
                 to `tsc -p <value>`.                    [string] [default: "."]
  -t, --tsc      Path to executable tsc, by default points to typescript
                 installed as dev dependency. Set to 'tsc' for global tsc
                         [string] [default: "./node_modules/typescript/bin/tsc"]
  -o, --opts     Path to mocha.opts file containing additional mocha
                 configuration.          [string] [default: "./test/mocha.opts"]
  -m, --mocha    Path to executable mocha, by default points to mocha installed
                 as dev dependency.
                           [string] [default: "./node_modules/mocha/bin/_mocha"]
  -g, --grep     Passed down to mocha: only run tests matching <pattern>[string]
  -f, --fgrep    Passed down to mocha: only run tests containing <string>
  -h, --help     Show help                                             [boolean]


Posted in Node Dot JS | Leave a comment


Posted in Node Dot JS | Leave a comment

Realm Problem After Installed\\Program Files\\Java\\jdk1.8.0_131
Posted in Mobile Development | Leave a comment