A lot of people are using Visual Studio Code to work with TypeScript and are getting annoyed by tslint warnings. TSLint is a piece of software that statically checks your code to find issues with how you wrote it. And at first one tries to fix the warnings, but since you already started on an existing project or template, there are a lot of warnings and you have work to do. Even worse, the warnings appear only when you open a file, so you think you're done until you start working in another area and you get red all over your project file. It's annoying! Therefore a lot of people just disable tslint.

But what if there was a way to check all the linting errors in your entire code? Even better, what if there were some magical way of fixing everything that can be fixed? Well, both of these exist. Assuming you have installed tslint globally (npm install tslint -g) you have these two commands to check and fix, respectively, all the errors in the current project:

tslint "src/**/*.ts?(x)" >lint_result
tslint "src/**/*.ts?(x)" --fix >fix_result

Note the src part, which tells tslint to look in the src folder and not in node_modules :-). If you prefer a more unsafe version that checks everything in the current directory, just replace src with a dot.

The fix option is only available from TSLint 4.0.

In ECMAScript 6 there is a Map class that looks and feels like a .NET Dictionary. As an extension of JavaScript, TypeScript code like this is totally valid:
let map:Map<number,string> = new Map<number,string>();
map[1]="Category One";
let name:string = map[1]; //name is now "Category One"

However, the code above is wrong. What this does is create a string property named "1" on the map object with a value "Category One". Its "size" is 0. The correct code would be like this:
let map:Map<number,string> = new Map<number,string>();
map.set(1,"Category One");
let name:string = map.get(1); //name is now "Category One", map.size is 1

Similar code for ECMAScript 6, you can just declare the map as let map = new Map();

Just in case you wonder why utilize this hard to use type instead of a normal object, it's a user choice. Most of the pros involve the type of the key (object keys can only be strings or symbols) and ease of counting and iterating, but these issues can be solved trivially in code, if ever needed.

Just a short info about HttpInterceptor, which is the Angular system of intercepting http requests, so you can do useful stuff like logging, error handling, authentication, etc. There are two npm packets for http, the old one is @angular/http and the new one is in @angular/common. While their interfaces are similar, HttpInterceptor only works for @angular/common/http.

Bonus thing: in the interceptor you are building, when you get the Observable<HttpEvent<any>> from next.handle, do not .subscribe to it, lest you will double all http requests (including adding items).

This is actually a TypeScript module resolution thing. The shape of the import name tells TypeScript what kind it is. The relative path imports always need a directory specified, so './myModule' and not 'myModule'. That's because myModule could be the name of an already declared ambient module.

Well, it's more to it, but the takeaway is that you have an import like import {something} from 'folder/something' and you want a similar import with a file from the same folder, you don't just delete folder/, you replace it with a dot, like this: import {somethingElse} from './something-else'