We Keep Coding

Why does Electron need to be saved as a developer dependency?

As per the official website, the correct way to save electron files is:
npm install electron --save-dev
Electron is actually required for running the app (quite literally: require()) and this goes against the top voted answer here. So why do we make this exception, if this is even one?

The fact that you require a package is irrelevant to whether it should be considered a dependency or a devDependency (in the npm sense). E.g. many projects use webpack API (i.e. const webpack = require('webpack')) but list it as a devDependency.
The reason is also explained in the post you link to: when you publish your package, if the consumer project needs other packages to use yours, then these must be listed as dependencies.
If your package uses some modules only for build, test, or bundles them into a dist file (i.e. what will be used by the consumer project), then those modules should not be mentioned in dependencies. We still list them in devDependencies for development.
Now in the case of an electron app, there is little chance you will consume your app as a node module of a consumer project, therefore the above convention is not really relevant.
Furthermore, we fall in the case where the electron package is bundled as part of the built output. There is no need for your user to get electron from npm to use your built app. Therefore it matches well the definition of a devDependency.
That being said, IIRC some electron packagers bundle your dependencies into the built app, so you still need some rigour in filling this list.

Cause those binary won't being used when you actually packaging into installer. Most of installer / packager for electron will build package with electron binaries, instead of using dependencies.

Sane approach to build and deploy typescript/node.js application

I'm working on node.js app that is written in Typescript, which means it needs to be compiled to JS before running. As I'm coming from java/jvm background where you ship prebuilt package to server and it gets run there I'm a bit afraid of the way of deployment where you push code to git and it's being built/compiled on server first and then run.
I don't like it for two main reasons:
dev dependencies need to be installed on server
deployment depends on external resources availability (npm etc).
I found NAR https://github.com/h2non/nar which is more or less what I wanted but it has some drawbacks (doesn't work with some deps that have native extensions).
My question is: is there any other "sane" way of doing deployment node.js deployment than this risky combination of npm install and tsc on server? Or should I let that sink in and do it that way?
To be honest I don't believe there are no more sane/reliable options for that.

What you can do (but there are probably other perfectly valid approaches) is building your project locally (or on a CI service), and only deploy this built version when you consider it as valid (tests, etc.).
This way, if something bad happens, like npm that fails, or a compilation error, you don't deploy anything, and you have time to resolve the situation.
For example, I used to have a gulp task (but it can be anything else: Grunt, a simple npm script...) that clone a production repository and build the project into this directory.
That way, I can check that my build is valid. If it is, I make a new commit and push it to the production repo, that is served the way you need (on a Heroku instance for example).
Pros
Clear separation of dev and non-dev dependencies
Deployment only when you know that the build is valid
No built files on source control on the development repository
No "live" dependency on external tasks like npm install or tsc build
Cons
You have two separated git repositories (one with the source code, one with the built version of your project)
Production process is a little bit heavier than simply committing to master
(From comment) Doesn't properly handle the case of npm package that relies on native extensions that have to be (re)built

is there any other "sane" way of doing deployment node.js deployment than this risky combination of npm install and tsc on server
package.json + npm install + tsc is the way to do it. Nothing risky about it.
More
Just use an npm script : https://github.com/TypeStrong/ntypescript#npm-scripts

What is node_modules directory in AngularJS?

I am exploring AngularJS tutorial project and found it has node_modules directory inside, which size if 60 megabytes.
Does simple clientside javascript project really need so huge corpus of unknown data?
I tried to delete this directory and project still works. I suspect it somehow relates with node.js and it's npm but how? Suppose I need to run my project on some conventional web server (not node.js), then how to know, which files/directories are unneeded?
Many javascript libraries require to use bower to install them. If I use bower, does this mean I need to keep node_modules?

The node_modules directory is only for build tools.
The package.json file in the app root defines what libraries will be installed into node_modules when you run npm install.
Very often with an angular app, on your dev machine or on a build server, you use other Javascript libraries from npm (a node.js package manager) to build your angular app. Tasks can be concatenating resources, using CSS preprocessors like LESS or SASS, minification, replacing of values, etc. etc. The most common tools for managing and running these tasks are called grunt and gulp, which are installed through npm as well.
When you deploy your app, you only distribute the resulting build, not any of the source files or build tools.
It is of course possible to write an AngularJS app without building anything.
edit from comments: When you dive into Angular more, there are more advanced techniques of using libraries installed by npm even in the client app, you then selectively choose the ones you need, not the whole 50MB+ thing. I'd recommend staying with the basic approaches until you get a good grasp on them though.

NPM is the node package manager, which installs packages locally into a project, specifically, into the node_modules folder. From there the package code can be included into a project, yes, can is the important word there.
The browser has no way to include modules in code (yet), so you need to use a library that can expose node's commonJS style modules. Browserify and Webpack are two popular methods of doing so.
Angular complicates this by introducing its own module system, which more closely resembles AMD-style modules. There are ways around this, so that you can use node-style modules, maybe your project uses those.
Using npm for managing dependencies is a great idea, its a fantastic package manager. It is likely in your case though that the project is only built using node and that the node_modules folder contains dependencies only related to the build.

Is there any maven like tool available for Ionic projects?

I'm having an Ionic project which I need to keep in github. When you start an Ionic project it auto generates a lot of library files. Do I need to keep all those library files while pushing the project to the github repo ? Is there something similar to maven available for Ionic projects which I can make use of ?

In JavaScript projects, we tend to use npm or bower. npm is the main one used these days (certainly has the largest ecosystem) and is also the one I mainly use, but bower certainly has quite a few front-end orientated modules that you can use.
npm comes packaged with NodeJS automatically; bower will require NodeJS to function as well, but is installed separately.

How do I use Express.js for a new web app after setup?

I already installed Express for a hello world app, and worked nice.Now I want create a new app, How can I use the already installed Express for that new app instead reinstalling it for that new app with : npm install express
Or do I have to re-install it frome internet everytime I create a new app?

npm install express
...will install Express only into the current folder path that you have in your terminal. If you want to install the package for all Node.js instances, you'll need to run:
npm -g install express
or, depending on your server's security model,
sudo npm -g install express
Sometimes you'll need to link the package if the linking failed (you'll get a "Cannot find module X" error), via:
sudo npm link express
If you want to read more about it, this blog post is a good read.

Use npm install -g express
But it worths adding express to your package.json with the rest of (future) dependencies you will need, so you can type npm install in your project's root and it will automatically install all the dependecies with the specified version and so on.

Don't install Express globally
Locally installing any package that you're going to depend on is generally considered a best practice in the Nodejs community. It comes down to managing dependencies.
See: Nodejs Blog - NPM 1.0: Global vs Local Installation
Consider the following scenario:
Lets say you do a global install of Express for your first project. You're start off using the latest version of the library and everything goes well. Then over time you write 10 more applications that depend on that install. Eventually Express hits the next main version and adds some killer features but they've also introduced a few backwards-incompatible API changes. You'll want to use the latest version for a new project but a global update will probably break all of the previous applications you've created.
In a best case scenario, you'll have 100% test coverage on all your old projects and through hard work and determination you will eventually manage to update/fix everything that broke with the update.
Realistically, nobody has 100% test coverage on everything and it's likely that something the update broke will be missed and accidentally pushed into production. ::cringe::
The scenario I just outlined is what lots of people refer to as dependency hell. It's a common reason why some organizations get locked into a specific version of a framework/application/dll.
With nodejs, it's cheap and easy to handle dependencies individually for each project. Modules generally aren't as monolithic (read huge) like the frameworks you'd expect in other languages.
To install Express locally with dependencies just use:
npm install express --save
Note: The --save flag will automatically add Express and the version number to your package.json file. If you want the module marked under the devDependencies listing instead, use the --save-dev flag.
The exception to the rule:
The exception to the don't install locally rule is CLI applications. It's rare that someone will write code that depends on a CLI application and -- even if they do -- CLI apps only superficially expose the highest-order functions. Unless the CLI has a development API that you're project depends on, it's probably safe and more convenient to install the package globally.
Aside: A library developer's perspective
As libraries are updated and improved it's not uncommon for library devs to change the API between major versions (ex 1.0, 2.0, 3.0) as they get a better feel for how the everything should be structured. When backwards-incompatible changes are introduced it's not uncommon for people to get all finger-pointy and start bickering about 'poor design'. Most of those issues have little to do with the design of the libraries being used. Rather, they're a cause of poor design and version management from the devs that implement them.
The truth of the matter is, it's impossible foresee a best possible design for a library until most of the code has already been implemented and put to use by a larger community. The best projects are those that grow organically, have a large userbase providing lots of valuable feedback, and adapt over time to their user's needs.
Major versions are usually the most exciting time for library devs because that's where we actually get to release ground-breaking changes. All the versions in between only serve to exist for boring maintenance and bugfixes.
One of the greatest benefits of Nodejs is it's small core. The Javascript language itself is well defined so there's little/no chance that updates to the core will break any code. The second greatest benefit of Nodejs is that the package manager along with the common package.json project file format make managing dependency versions as easy and straightforward as possible.
Source: I develop libraries and spend an obscene amount of time thinking about good API design.