10 Essential TypeScript Tips and Tricks for Angular Devs

In this article, we’ll dive into a set of tips and tricks that should come in handy in every Angular project and beyond when dealing with TypeScript.
In recent years, the need for static typing in JavaScript has increased rapidly. Growing front-end projects, more complex services, and elaborate command-line utilities have boosted the need for more defensive programming in the JavaScript world. Furthermore, the burden of compiling an application before actually running it hasn’t seen as a weakness, but rather as an opportunity. While two strong parties (TypeScript and Flow) have emerged, a lot of trends actually indicate that only one may prevail — TypeScript.
Besides the marketing claims and commonly known properties, TypeScript has an amazing community with very active contributors. It also has one of the best teams in terms of language design behind it. Led by Anders Hejlsberg, the team has managed to fully transform the landscape of large-scale JavaScript projects to be nearly an exclusively TypeScript-powered business. With very successful projects such as VSTS or Visual Studio Code, Microsoft themselves is a strong believer in this technology.
But it’s not only the features of TypeScript that make the language appealing, but also the possibilities and frameworks that TypeScript is powering. Google’s decision to fully embrace TypeScript as their language of choice for Angular 2+ has proven to be a win-win. Not only did TypeScript gain more attention, but also Angular itself. Using static typing, the compiler can already give us informative warnings and useful explanations of why our code will not work.
TypeScript Tip 1: Supply Your Own Module Definitions
TypeScript is a superset of JavaScript. As such, every existing npm package can be utilized. While the TypeScript eco-system is huge, not all libraries are yet delivered with appropriate typings. Even worse, for some (smaller) packages not even separate declarations (in the form of @types/{package}) exist. At this point, we have two options:

bring in legacy code using TypeScript tip 7
define the API of the module ourselves.

The latter is definitely preferred. Not only do we have to look at the documentation of the module anyway, but typing it out will prevent simple mistakes during development. Furthermore, if we’re really satisfied with the typings that we just created, we can always submit them to @types for including them on npm. As such, this also rewards us with respect and gratefulness from the community. Nice!
What’s the easiest way to supply our own module definitions? Just create a module.d.ts in the source directory (or it could also be named like the package — for example, unknown-module.d.ts for an npm package unknown-module).
Let’s supply a sample definition for this module:
declare module ‘unknown-module’ {
const unknownModule: any;
export = unknownModule;
}

Obviously, this is just the first step, as we shouldn’t use any at all. (There are many reasons for this. TypeScript tip 5 shows how to avoid it.) However, it’s sufficient to teach TypeScript about the module and prevent compilation errors such as “unknown module ‘unknown-module’”. The export notation here is meant for the classic module.exports = … kind of packages.
Here’s the potential consumption in TypeScript of such a module:
import * as unknownModule from ‘unknown-module’;

As already mentioned, the whole module definition is now placed in the type declaration of the exported constant. If the exported content is a function, the declaration could look like this:
declare module ‘unknown-module’ {
interface UnknownModuleFunction {
(): void;
}
const unknownModule: UnknownModuleFunction;
export = unknownModule;
}

Of course, it’s also possible to use packages that export functionality using the ES6 module syntax:
declare module ‘unknown-module’ {
interface UnknownModuleFunction {
(): void;
}
const unknownModule: UnknownModuleFunction;
export const constantA: number;
export const constantB: string;
export default unknownModule;
}

TypeScript Tip 2: Enum vs Const Enum
TypeScript introduced the concept of enumerations to JavaScript, which did represent a collection of constants. The difference between
const Foo = {
A: 1,
B: 2,
};

and
enum Foo {
A = 1,
B = 2,
}

is not only of syntactical nature in TypeScript. While both will be compiled to an object (i.e., the first one will just stay as is, while the latter will be transformed by TypeScript), the TypeScript enum is protected and contains only constant members. As such, it would not be possible to define its values during runtime. Also, changes of these values will not be permitted by the TypeScript compiler.
This is also reflected in the signature. The latter has a constant signature, which is similar to
interface EnumFoo {
A: 1;
B: 2;
}

while the object is generalized:
interface ConstFoo {
A: number;
B: number;
}

Thus we wouldn’t see the values of these “constants” in our IDE. What does const enum now give us? First, let’s look at the syntax:
const enum Foo {
A = 1,
B = 2,
}

This is actually the same — but note, there’s a const in front. This little keyword makes a giant difference. Why? Because under these circumstances, TypeScript won’t compile anything. So we have the following cascade:

objects are untouched, but generate an implicit generalized shape declaration (interface)
enum will generate some boilerplate object-initializer along with a specialized shape declaration
const enum doesn’t generate anything beside a specialized shape declaration.

Now how is the latter then used in the code? By simple replacements. Consider this code:
enum Foo {
A = 1,
B = 2
}

const enum Bar {
A = 1,
B = 2
}

console.log(Bar.A, Foo.B);

Here we end up in JavaScript with the following outcome:
var Foo;
(function (Foo) {
Foo[Foo[“A"] = 1] = "A";
Foo[Foo["B"] = 2] = "B";
})(Foo || (Foo = {}));
console.log(1 /* A */, Foo.B);

Note that 5 lines alone have been generated for enum Foo, while enum Bar only resulted in a simple replacement (constant injection). Thus const enum is a compile-time only feature, while the original enum is a runtime + compile-time feature. Most projects will be well suited for const enum, but there may be cases where enum is preferred.
Continue reading %10 Essential TypeScript Tips and Tricks for Angular Devs%

Link: https://www.sitepoint.com/10-essential-typescript-tips-tricks-angular/

10 Essential Sublime Text Plugins for JavaScript Developers

In this article, I’ll outline ten must-have Sublime Text plugins for JavaScript developers, each of which can improve your workflow and make you more productive.
Sublime Text is a great application for just about any developer to have in their toolbox. It’s a cross-platform, highly customizable, advanced text editor that sits nicely between full featured IDEs (which are notoriously resource hungry) and command line editors such Vim or Emacs (which have steep learning curves).
In recent years, Sublime has gained welcome competition from both Visual Studio Code and Atom, but Sublime Text still holds its own by being indisputably faster, being able to open larger files faster than the others.
One of the things that makes Sublime so great is its extensible plugin architecture. This makes it easy for developers to extend Sublime’s core functionality with new features like code completion, or the embedding of remote API documentation. Sublime Text doesn’t come with plugins enabled out of the box: they’re typically installed through a 3rd-party package manager simply called Package Control. To install Package Control in Sublime Text, please follow the installation guide on their website.
So let’s get to it!
1. Babel
Of course, the first one on my list is the Babel plugin. This plugin adds proper syntax highlighting to your ES6/2015 and React JSX code. After installing the plugin, the first thing you should do is set it as the default syntax for all of your JavaScript and TypeScript file types.
If you haven’t yet discovered the joy of Babel, I highly suggest it. It allows you to compile ES6/ES7/ESNext, JSX, and TypeScript code down to ES5 for full browser support. It integrates well with all popular build tools and the CLI. Obviously, it doesn’t support legacy browsers, but you can follow the tips on their caveats page if you need to support IE10 and below.

2. SublimeLinter
Next up is SublimeLinter, which provides amazing ESLint and JSHint integration into Sublime. A linter will look over your code and verify it has proper styling and proper syntax based on a configuration file that can be checked in with your source code. No matter if you’re a beginner or have been programming for most of your life: in JavaScript, a linter is a must have. Check out the ESLint or JSHint about pages to see what they can do for you. Depending on which you chose for your project, you’ll also need the supporting packages of SublimeLinter-eslint or SublimeLInter-jshint.
In order for either of these to work, you must include a linter either into your project dependencies or install it globally:
npm install –save-dev eslint

If you’re unsure how to use npm, check out our tutorial on getting started with Node Package Manager.

If you’ve installed and configured it correctly, you should see the changes when you open or save a JavaScript file. The plugin is incredibly configurable and can be made to report in a number of ways that might be better for your workflow. By default, the description of the errors will be reported in the status bar at the bottom of the editor.
Continue reading %10 Essential Sublime Text Plugins for JavaScript Developers%

Link: https://www.sitepoint.com/essential-sublime-text-javascript-plugins/

Fun With Angular: A Quick Overview

Angular in the Real World
Angular is one of the more popular JavaScript frameworks in use today. With the backing of a huge company (Google) and the widespread use in the corporate world, it certainly deserves consideration when you are planning your next app development. In this blog post, I’ll take a quick look at the key features of Angular.
Angular was created by Google and was originally released in 2010 as AngularJS – the 1.x version. The initial release of the Angular 2.x version was on September 14, 2016. While the initial release of preview alpha and beta versions existed in 2015, fall 2016 is when we started to see some real traction in its use.

Link: https://dzone.com/articles/fun-with-angular-a-quick-overview?utm_medium=feed&utm_source=feedpress.me&utm_campaign=Feed%3A+dzone%2Fwebdev

How to JavaScript in 2018

Last year many people, including myself, were talking about JavaScript fatigue. No, the ways to write a JavaScript application have not really slimmed down, BUT with a lot of command-line tools doing much of the heavy lifting, transpiling becoming less crucial and TypeScript trying to minimize type errors, we can relax a little.
Note: This blog post is part of our whitepaper, “The Future of JavaScript: 2018 and Beyond," which offers our future-looking analysis and predictions about the latest in JavaScript.

Link: https://dzone.com/articles/how-to-javascript-in-2018?utm_medium=feed&utm_source=feedpress.me&utm_campaign=Feed%3A+dzone%2Fwebdev

Building an Angular 5 Application Step-By-Step

In this article, we will be building an Angular 5 application from scratch with step-by-step configuration and explanation. This single page application will be created using an Angular CLI command with different Angular modules integrated into it, such as RouterModule, HttpClientModule, AppRoutingModule, and FormsModule. The application will have a sample login page styled with Bootstrap and a user dashboard page. Once the user is authenticated successfully, they will be redirected to the dashboard page where they can see a list of users.
What’s New in Angular 5
Angular 5 applications are faster, lighter, and easy to use. They have material design capabilities to build beautiful and intuitive UIs. A new HttpClientModulewas introduced which is a complete rewrite of the existing HttpModule. It now supports TypeScript 2.4.

Link: https://dzone.com/articles/building-angular5-application-step-by-step?utm_medium=feed&utm_source=feedpress.me&utm_campaign=Feed%3A+dzone%2Fwebdev

Typing Arrays in TypeScript

There are many ways we can type a property to declare to TypeScript something is an array, or contains an array of “something”. We have generic types, array types and type assertions.
For the purposes of this article, we’ll simply use a TypeScript class to demonstrate how we can declare some of these properties, in the various forms.

Table of contents

Type Inference
Declaring an Array Type
Using Array Generic Types

Type Inference
Before we explore the benefits of explicit typing, let’s consider a class with an array. This will infer the type of an array:
// inferred as messages: any[]
class Chats {
messages = [];
}

And we can again, infer:
// inferred as messages: number[]
class Chats {
messages = [1, 2, 3];
}

We can of course mix and match our types, and TypeScript will infer as best as possible:
// inferred as messages: (string | number)[]
class Chats {
messages = [‘A’, ‘B’, 1, 2];
}

This is great for well defined APIs, return statements and such that we are fully confident we want to infer. So let’s explore the main ways we can type an array in TypeScript.
Declaring an Array Type
Before we continue, let’s introduce a second class member, the single Message:
class Message {
constructor(private from: string, message: string) {}
}

// create a new message
new Message(‘Todd Motto’, ‘Hey, you around?’);

Our Chats class can now be sensibly typed like so:
class Chats {
messages: Message[] = [];
}

We assign what looks like an array, but we know it’s a type as we’re using : before the array assignment. Interestingly, outside of the array [] type, we specify what the array contains, i.e. Message[].

Learn more about using Classes as Types here!

In this case, we’re expecting only an array of messages.
We could in fact just declare the properties on the class, and assign the property’s value perhaps in the constructor.
class Chats {
messages: Message[];
constructor() {
this.messages = [];
}
}

In Angular, this is typically done inside the ngOnInit lifecycle hook:
class Chats implements OnInit {
messages$: Observable;

constructor(private store: Store<State>) {}

ngOnInit() {
this.messages$ = this.store.select(‘messages’);
}
}

A more comprehensive example, but we digress. However – you may have noticed Observable<Message[]>. Have you seen this before? If not, let’s explain because the same principle applies when typing arrays.
Using Array Generic Types
Generic types in TypeScript are essentially ways to make things more… generic.
Generics are parameterised types, where we can either let TypeScript infer the type for us, or we can specify it ourselves. Using a generic type in TypeScript alongside an array looks like this (which is the equivalent to what we’ve covered above):
class Chats {
messages: Array<Message> = [];
}

There’s no functional difference between using a generic instead of a normal typing, however depending on your use case and complexity of types – you may wish to opt for one over the other.
Another nice thing about generics is that we can combine initialisation and also infer the type, creating a new array whilst passing the generic type:
// inferred as messages: Message[]
class Chats {
messages = new Array<Message>();
}

So, why do we have multiple ways to declare an array? TypeScript is pretty wild at times, and we have many ways to do things – TypeScript provides us a lot of options alongside that.
There are actually a few more ways to type an array as well (but I’d stick with the things we’ve covered above for sanity):
// I’d go for this option
class Chats {
messages: Message[] = [];
}

// Looks a little more oldschool, but same as above
class Chats {
messages: Array<Message> = new Array();
}

// Don’t do this unless you need to assert the type
class Chats {
messages = [] as Message[];
}

// And really, don’t do this
class Chats {
messages = <Array<Message>>[];
}

As the saying goes, “A typed array keeps the errors away”…
Okay that was terrible. Be smart, type your code and enjoy!

Link: https://toddmotto.com/typing-arrays-typescript

Introduction to TypeScript

Since its inception, JavaScript has experience monumental growth.
The language has expanded its application domain far beyond the browser. It is now used to power up backends, create hybrid mobile applications, architect cloud solutions, design neural networks and even control robots! The versatility of JavaScript paired with its high adoption rate has created an increasing demand for scalable, secure, performant and feature-rich JavaScript applications, which in turn has created a need for tooling, libraries and frameworks that make it easier and faster to write applications that meet those expectations.
This demand for high performance JavaScript led to the introduction of TypeScript.
Let’s explore in detail what are the design goals and benefits that using TypeScript brings to any codebase – from a small side project to a large enterprise one.
If you’d like to learn more about TypeScript, come and join me over at Ultimate Angular to take a deep dive – and grow your skills!

Table of contents

TypeScript is a Superset of JavaScript
TypeScript Architecture: Design Goals
JavaScript Compatibility with TypeScript
Giving Type Check to JavaScript
More Powerful JavaScript Object Oriented Programming
Zero Overhead

TypeScript Architecture: Components
Language
Core TypeScript Compiler
Parser
Binder
Type Resolver or Type Checker
Emitter
Pre-processor

TypeScript Standalone Compiler, tsc
Language Service
Tool Integration

Setting Up and Using TypeScript
How to Install TypeScript
Create a TypeScript File
Compile TypeScript
Configure TypeScript using tsconfig
TypeScript Playground
Conclusion

TypeScript is a Superset of JavaScript
TC39, the committee that regulates the development of JavaScript, has introduced new features to the language with each release version. Recently added features such as classes and block-scoped variables make standard JavaScript more robust. However, the language can be further enhanced and hardened to handle highly complex architectural demands in a reliable and predictable way. TC39 oftentimes has features in its pipeline that would help achieve that architectural goal but it takes time for them to become part of the standard language and to be supported by all major browsers.
As each new version of JavaScript extends the previous one, we could think of “Future JavaScript” as a superset of the current standard one. With that model in mind, TypeScript was created to act as that superset of JavaScript that puts the future of the language in the hands of today’s developers. Moreover, TypeScript integrates features outside of the scope of TC39, such as type-checking, generics and interfaces, that mitigate many points of failure present in JavaScript and rev up development – all provided through abstractions written in JavaScript. All that TypeScript gives you is convenient syntactic sugar that eventually gets all converted to cross-platform JavaScript.
Let’s explore in detail the architecture and components of TypeScript to understand its benefits deeply.
TypeScript Architecture: Design Goals
Microsoft designed TypeScript with specific architectural parameters in mind that allow TypeScript to integrate fully and easily with existing JavaScript code while providing robust features external to JavaScript.
JavaScript Compatibility with TypeScript
As we’ve established, TypeScript is a superset of JavaScript. This relationship permits TypeScript to understand and work with any code that is valid JavaScript. Any valid JavaScript code is valid TypeScript code with only a few exceptions: handling option function parameters and assigning a value to an object literal.
Do take note that valid TypeScript is not valid JavaScript code. TypeScript contains syntax and abstractions that do not exist in JavaScript and using them with JavaScript would generate JavaScript runtime errors. However, in an effort to promote compatibility, TypeScript developers align the language with the pipeline of ECMAScript. Current and future ECMAScript proposals are considered when designing new TypeScript features.
Giving Type Check to JavaScript
JavaScript being a loosely typed language is extremely lenient on the value assigned to its variables and it creates no structural contracts of any kind between those variables and the constructs that use them. Passing a number argument to a function that expects a string parameter generates no errors in JavaScript during development but will create havoc during runtime when the body of the function is not able to use that argument correctly.
To prevent these runtime issues, TypeScript was designed as a strongly typed language that performs static type-checking during its compilation time to JavaScript. For flexibility, the type-checking capabilities of TypeScript are optional; however, most of TypeScript key benefits revolve around type-checking – it’s the main reason to use TypeScript! For example, type-checking lets the language service layer of the language to be used for creating better tools that maximize your productivity while reducing the instance of errors.
More Powerful JavaScript Object Oriented Programming
The syntactic sugar provided by TypeScript will allow us to reduce the footprint of our code significantly while increasing its expressiveness. TypeScript makes writing class object-oriented code a breeze. It provides us with classes, interfaces and modules that allow us to properly structure our code in encapsulated reusable structures that makes it easy to maintain and scale. Within classes, we are also able to specify the visibility level of class properties and methods by using TypeScript provided modifiers – public, private and protected. There are many other abstractions that will make us happy and productive developers!
Zero Overhead
As TypeScript developers, we work in two different contexts – design and execution. In the design context, we use TypeScript directly to write our application. Now, since TypeScript is not supported by any browser, in order to make our design code work, it has to become JavaScript code. In the execution context, all of our TypeScript code is compiled into JavaScript code and is then executed by its target platform – the browser for example. The browser has no clue that this code is compiled – it looks just like the plain JavaScript it knows how to execute. Therefore, TypeScript imposes no runtime overhead on any application.
For the browser to receive valid execution code, the TypeScript compiler takes TypeScript features and implements them in whatever JavaScript compile target of our choice – we can go as early as ES3! As we know, there are some TypeScript features that simply do not exist in JavaScript and cannot be implemented, such as type-checking and interfaces. These unsupported features are simply removed from the compiled code – this is known as type erasure. Their removal has no impact on the functionality of your code because these unique features are there only to help TypeScript enhance your developer experience and they don’t overrun or override anything core to the JavaScript language.
TypeScript Architecture: Components
The architecture of TypeScript is neatly organized in different layers.
Language
Core TypeScript Compiler
Sometimes called the TypeScript transpiler, the TypeScript compiler has the core task of managing the low-level mechanics of type-checking our code and converting it into valid JavaScript code. The compiler uses static code analysis to mitigate the occurrence of runtime errors. Typos in our code or passing the wrong type of argument to a function will make the compiler throw compile-time errors to warn us that something is wrong before we even execute the code. This is extremely valuable as, even with the most comprehensive suite of tests, logic errors and edge cases can crash our application at runtime. TypeScript ensures that type definitions that we create within our code are used consistently throughout it.
The compiler itself is made up of different parts that work together fast to make our code predictable and to compile it:
Parser
A quiet complex yet critical component that takes input data, our TypeScript source files, and builds a data structure from it – in this case, an Abstract Syntax Tree. Parsing our code creates a structural representation of the sources that allows us to check that they are following the language grammar – that is, that the sources are built using the correct syntax.
Binder
When we have, for example, a function and a module with the same name, the binder links these named declarations using a Symbol, allowing the type system to make sense of them.
Type Resolver or Type Checker
This component resolves types for each construct, checks semantic operations and generates type diagnostics.
Emitter
Generates output from .ts and d.ts files. The output can be either a JavaScript file (.js), a TypeScript definition file, (d.ts), or a source map file (.js.map).
Pre-processor
Resolves and manages references amongst files using import or /// \.

We will learn in an upcoming section how to setup and configure the TypeScript compiler.

TypeScript Standalone Compiler, tsc
We’ll shortly explore the installation and usage of the standalone TypeScript compiler. Referred to often as tsc, it is a high-level compiler that takes a TypeScript file, .ts, and outputs a JavaScript file, .js.
Language Service
This component layer sits on top of the core TypeScript compiler and provides features that are needed for IDEs and text editors to do their job, such as statement completions, signature help, code formatting and outlining, syntax highlighting and many more. The language service also powers code refactoring such as renaming variables, debugging and incremental compilation.
Tool Integration
TypeScript offers type annotations that allow IDEs and text editors to perform comprehensive static analysis on our code. These annotations allow these tools to make smart suggestions by making our code far more predictable. In return, IDEs and text editors can offer better auto completion and refactoring of TypeScript code.
Setting Up and Using TypeScript
How to Install TypeScript
The easiest way to get TypeScript up and running is by installing its standalone compiler (tsc) globally via a Node.js package manager such as npm or yarn.
npm install -g typescript

or
yarn global add typescript

Once this global installation of the TypeScript compiler is complete, we have access to the tsc command from our terminal that allow us to compile .ts files into .js ones. We can verify the success of our compiler installation by running the following command to check its version:
tsc -v

The TypeScript compiler comes with many options that we’ll be exploring as we move forward. For now, create a folder anywhere in your file system called ts-intro. We are going to use that folder to store our TypeScript source files and take it for a spin!
Create a TypeScript File
Using a text editor, IDE or terminal – whatever option you prefer – create a file named barista.ts. Within our file, we are going to create a barista function that takes name and outputs an order call using that name:
// barista.ts

function barista(name) {
console.log(‘Peppermint Mocha Frappuccino for ‘ + name);
}

let customer = {
name: ‘Todd’,
};

barista(customer.name);

We’ve created a valid TypeScript file but how do we run it? Let’s do that next.
Compile TypeScript
With our folder ts-intro as our current directory, let’s execute the following command in our terminal window:
tsc barista.ts

We get barista.js being added to our folder ts-intro – this is the output of the compilation. Open barista.js and notice that it’s almost exactly the same as barista.ts:
// barista.js

function barista(name) {
console.log(‘Peppermint Mocha Frappuccino for ‘ + name);
}
var customer = {
name: ‘Todd’,
};
barista(customer.name);

One way to quickly spot what changed through compilation is by running a difference on the content of both files:
OSX / Linux: diff barista.ts barista.js
Windows: FC barista.ts barista.js
The file difference is nothing major. tsc changed the scoped variable let to var. This happened because the default target JavaScript for compilation is ES3 – which doesn’t support let. We’ll learn soon on how to modify the compiler configuration. We can now run barista.js through node by executing the following command:
node barista.js

As it is, barista.ts has no TypeScript on it, hence, there’s not much to compile. Let’s add more TypeScript features to it to see a more dramatic file change.
Let’s drastically modify the code by creating a Barista class that has a static method that calls the order and uses type annotations to enforce type checking of our variables:
// barista.ts

class Barista {
static callOrder(name: string) {
console.log(‘Peppermint Mocha Frappuccino for ‘ + name);
}
}

let customer = {
name: ‘Todd’,
};

Barista.callOrder(customer.name);

Because callOrder is static, we do not need to create an instance of the class to be able to use the method. Much like Array.from, we call the method from the class name itself. Compile the code running tsc barista.ts again and note how this time we get a quite different barista.js:
// barista.js

var Barista = /** @class */ (function() {
function Barista() {}
Barista.callOrder = function(name) {
console.log(‘Peppermint Mocha Frappuccino for ‘ + name);
};
return Barista;
})();
var customer = {
name: ‘Todd’,
};
Barista.callOrder(customer.name);

ES3 supports no class construct, therefore, this TypeScript construct has to be implemented in plain JavaScript. Notice, however, how nice and readable the compiled code is! The compiler created a comment annotation, @class, in the JavaScript file to denote Barista as intended to be a class – increasing our code readability.
Configure TypeScript using tsconfig
Much like package.json is added to give npm instructions on what packages to install as project dependencies, we can use a tsconfig.json file to provide instructions on how our TypeScript project should be configured. Adding tsconfig.json to ts-intro marks the folder as the root directory of our TypeScript project. In this file, we can specify compiler options to compile our .ts files as well as root files for our project.
Create a tsconfig.json file within ts-intro with the following configuration to tell the compiler to use ES6 as the JavaScript compilation target instead:
{
“compilerOptions": {
"target": "es6"
}
}

From now on, whenever we run the tsc command, the compiler will check this file first for special instructions and then proceed with compilation based on those instructions. It’s important to know that to make use of tsconfig.json, we do not specify any file inputs to tsc. To compile barista.ts once again under this new configuration simply run the command tsc in your terminal.
Since we are using ES6, which supports class, as the JavaScript compilation target, barista.js doesn’t look very different than barista.ts! The only difference is that the compiler removed the code related to static type checking. The name argument doesn’t have any annotations to indicate its type since this feature is not part of ES6.
There’s a much easier way to initialise a TypeScript project and create its tsconfig.json file. We can use a handy shortcut similar to what’s done to kickstart a Node.js project. Let’s go ahead and delete the tsconfig.json file that we created and then run the following initialisation command:
tsc –init

The output of running this command is a newly created tsconfig.json file that is packed with a lot of default options to configure our TypeScript project compiler – most of them are not enabled by default. The configuration options are accompanied by comments that explain what each one configures in our compiler!
{
"compilerOptions": {
/* Basic Options */
"target":
"es5" /* Specify ECMAScript target version: ‘ES3’ (default), ‘ES5’, ‘ES2015’, ‘ES2016’, ‘ES2017’, or ‘ESNEXT’. */,
"module":
"commonjs" /* Specify module code generation: ‘none’, commonjs’, ‘amd’, ‘system’, ‘umd’, ‘es2015’, or ‘ESNext’. */,
// "lib": [], /* Specify library files to be included in the compilation: */
// "allowJs": true, /* Allow javascript files to be compiled. */
// "checkJs": true, /* Report errors in .js files. */
// "jsx": "preserve", /* Specify JSX code generation: ‘preserve’, ‘react-native’, or ‘react’. */
// "declaration": true, /* Generates corresponding ‘.d.ts’ file. */
// "sourceMap": true, /* Generates corresponding ‘.map’ file. */
// "outFile": "./", /* Concatenate and emit output to single file. */
// "outDir": "./", /* Redirect output structure to the directory. */
// "rootDir": "./", /* Specify the root directory of input files. Use to control the output directory structure with –outDir. */
// "removeComments": true, /* Do not emit comments to output. */
// "noEmit": true, /* Do not emit outputs. */
// "importHelpers": true, /* Import emit helpers from ‘tslib’. */
// "downlevelIteration": true, /* Provide full support for iterables in ‘for-of’, spread, and destructuring when targeting ‘ES5’ or ‘ES3’. */
// "isolatedModules": true, /* Transpile each file as a separate module (similar to ‘ts.transpileModule’). */
/* Strict Type-Checking Options */
"strict": true /* Enable all strict type-checking options. */
// "noImplicitAny": true, /* Raise error on expressions and declarations with an implied ‘any’ type. */
// "strictNullChecks": true, /* Enable strict null checks. */
// "noImplicitThis": true, /* Raise error on ‘this’ expressions with an implied ‘any’ type. */
// "alwaysStrict": true, /* Parse in strict mode and emit "use strict" for each source file. */
/* Additional Checks */
// "noUnusedLocals": true, /* Report errors on unused locals. */
// "noUnusedParameters": true, /* Report errors on unused parameters. */
// "noImplicitReturns": true, /* Report error when not all code paths in function return a value. */
// "noFallthroughCasesInSwitch": true, /* Report errors for fallthrough cases in switch statement. */
/* Module Resolution Options */
// "moduleResolution": "node", /* Specify module resolution strategy: ‘node’ (Node.js) or ‘classic’ (TypeScript pre-1.6). */
// "baseUrl": "./", /* Base directory to resolve non-absolute module names. */
// "paths": {}, /* A series of entries which re-map imports to lookup locations relative to the ‘baseUrl’. */
// "rootDirs": [], /* List of root folders whose combined content represents the structure of the project at runtime. */
// "typeRoots": [], /* List of folders to include type definitions from. */
// "types": [], /* Type declaration files to be included in compilation. */
// "allowSyntheticDefaultImports": true, /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */
// "preserveSymlinks": true, /* Do not resolve the real path of symlinks. */
/* Source Map Options */
// "sourceRoot": "./", /* Specify the location where debugger should locate TypeScript files instead of source locations. */
// "mapRoot": "./", /* Specify the location where debugger should locate map files instead of generated locations. */
// "inlineSourceMap": true, /* Emit a single file with source maps instead of having a separate file. */
// "inlineSources": true, /* Emit the source alongside the sourcemaps within a single file; requires ‘–inlineSourceMap’ or ‘–sourceMap’ to be set. */
/* Experimental Options */
// "experimentalDecorators": true, /* Enables experimental support for ES7 decorators. */
// "emitDecoratorMetadata": true, /* Enables experimental support for emitting type metadata for decorators. */
}
}

The best part of this new tsconfig.json is definitely how well documented the options are – they are pretty self-explanatory! You don’t have to use all of these options though. For most of my Angular applications that use TypeScript, I use the following configuration:
{
"compilerOptions": {
"target": "es6",
"module": "commonjs",
"outDir": "dist",
"sourceMap": true,
"experimentalDecorators": true
},
"files": [
"./node_modules/@types/mocha/index.d.ts",
"./node_modules/@types/node/index.d.ts"
],
"include": ["src/**/*.ts"],
"exclude": ["node_modules"]
}

Note that es6 and ES2015 can be used interchangeably.

I added three additional properties to tsconfig.json (files, include and exclude) that allow us to specify which files in the containing directory and subdirectories should be compiled:

When files or include properties are specified, the compiler will only process a union of the files listed as the value of these properties.
files takes a list of relative or absolute file paths, whereas include and exclude take a list of glob-like file patterns.
exclude is used to filter the files listed under include; however, any files that have been explicitly listed under files are always included regardless of them matching any pattern defined under exclude.

I presented my tsconfig.json as an example to showcase the file filtering capabilities of the compiler. Running tsc with it in our ts-intro folder will give us an error saying that the paths specified in files are not found. Again, I use this for my Angular projects that makes use of node_modules – if you wish, give it a try on your projects.
We’ve covered a lot so far. We’ve learned how to create a TypeScript file, how to compile a TypeScript file, and how to configure the compiler to render different compilations of a TypeScript file. There’s much, much more that can be configured through tsconfig.json but that’s a story for another post!
TypeScript Playground
Whenever you need to perform some quick experimentation with how TypeScript code would compile to JavaScript it’s not necessary to go through all this setup. The TypeScript Team created an online tool that allows us to compile TypeScript code and compare it side by side with its JavaScript output online. This tool is called TypeScript Playground and we can access it at typescriptlang.org/play.
TypeScript Playground allows you to share the code snippets you create there with others. You can access the Playground for barista.ts here.
The Playground also has built-in examples that showcase TypeScript code snippets of different complexities and categories, such as using generics. Use it at your leisure to create deep mapping knowledge between TypeScript and JavaScript easily.
Conclusion
TypeScript brings a lot of benefits to our productivity and developer experience. We’ve seen that integrating it with an existing JavaScript project is easy and carries little to no overhead. TypeScript is not unique to Angular, other powerful frontend frameworks such as React and Vue are starting to be used with TypeScript to allow developer teams to create applications that are reliable, sustainable and scalable. JavaScript and TypeScript are continually evolving but not competing against each other. TypeScript was created to complement and enhance JavaScript – not replace it. The future may see them becoming very similar in features but with TypeScript remaining the statically typed alternative.
With this TypeScript introduction, we’ve just scratched the surface of all the amazing things that we can do with TypeScript. I hope you enjoyed this post!
If you’re interested in taking your TypeScript skills to an ultimate level, I invite you to come and learn TypeScript basic and advanced concepts with me at Ultimate Angular – don’t worry if you are not an Angular developer, the course is designed completely around TypeScript!

Link: https://toddmotto.com/typescript-introduction

Angular Developer: JavaScript to TypeScript

New JavaScript frameworks and libraries are created every day. This generates a dilemma: which solution should we use when starting a project?
My web development experience over the last few years has mainly included the AngularJS and Backbone.js frameworks. Angular, jQuery, and traditional JavaScript have been in my comfort zone. When I ended up coming face-to-face with TypeScript, it felt new, scary, and pretty confusing. I want to make that transition easier for you!

Link: https://dzone.com/articles/angular-developer-javascript-to-typescript?utm_medium=feed&utm_source=feedpress.me&utm_campaign=Feed%3A+dzone%2Fwebdev