Michael Bryan

Michael Bryan

1565161882

TypeScript with Babel: A Beautiful Marriage

Originally published by Matt Turnbull  at  medium.com

Discover four reasons why TypeScript and Babel are a perfect pair, and follow a step-by-step guide to upgrade your project with TypeScript in 10 minutes.

Huh? What? Why?

I didn’t understand the need for this new preset at first.


Aren’t Babel and TypeScript two completely different things? How can Babel handle the TypeScript type checking? TypeScript can already output to ES5 just like Babel can, so what’s the point? Isn’t merging Babel and TypeScript complicating things?

After hours of research, my conclusion:

TypeScript and Babel are a beautiful marriage.

Let me show you.

1) You already use Babel (or should).

You’re in one of these three categories:


  1. You already use Babel. If not directly, then your Webpack config feeds *.js files into Babel (this is the case for most boilerplates, including create-react-app).
  2. You use Typescript without Babel. Consider adding Babel to your arsenal, it provides many unique features. Read on.
  3. You don’t use Babel? It’s time to jump on board.

Write modern JavaScript without breaking anything.

Your JavaScript code needs to run in an old browser? No problem, Babel converts the code and makes everything a-okay. Use the latest and greatest features without worry.


The TypeScript compiler has a similar feature, enabled by setting target to something like "ES5" or "ES6". But the Babel configuration improves on this with babel-preset-env. Instead of locking in a specific set of JavaScript features (ES5, ES6, etc), you list the environments you need to support:

"targets": {
    "browsers": ["last 2 versions", "safari >= 7"],
    "node": "6.10"
}

Babel uses compat-table to check which JavaScript features to convert and polyfill for those specific target environments.

Take a moment to appreciate the genius who named this project ‘compat-table’.

An interesting technique used by create-react-app: compile with the latest browsers during development (for speed), and compile with a larger range of browsers in production (for compatibility). Nice.

Babel is super configurable.

Want React with JSX? Flow? TypeScript? The shiny new optional chainingproposal? Just install a plugin and let Babel handle it.


@babel/plugin-proposal-optional-chaining

There’s also a great selection of third-party Babel plugins. Using Styled Components? Improve server side rendering. Using Ramda? Easily compose functions. Want more? Manage feature flagsimprove lodash importsenhance console.log, or strip console.log. Whatever floats your boat, you’ll find it on this mega list: awesome-babel.

Better than console.log: babel-plugin-console

Macros!

You know Kent C Dodds? He’s created a game-changing Babel plugin: babel-plugin-macros.


Instead of adding plugins to your Babel config file, you import macros directly in your JavaScript code. At build time, the macro kicks in and modifies the code. Check out this post for more details.

I think Babel macros will explode this year. Not only is it an amazing concept, but it’s already integrated into create-react-app v2.0 (beta), which pushes the community support.

2) It’s easier to manage ONE compiler.

TypeScript requires it’s own compiler — it’s what provides the amazing type checking superpowers.


In the gloomy days (before Babel 7).

Chaining together two separate compilers (TypeScript and Babel) is no easy feat. The compilation flow becomes: TS > TS Compiler > JS > Babel > JS (again).


Webpack is often used to solve this problem. Tweak your Webpack config to feed *.ts into TypeScript, and then feed the result into Babel. But which TypeScript loader do you use? Two popular choices are ts-loader and awesome-typescript-loader. The README.md for awesome-typescript-loadermentions it might be slower for some workloads, and recommends ts-loaderwith HappyPack or thread-loader. The README.md for ts-loader recommends combining with fork-ts-checker-webpack-pluginHappyPackthread-loader, and / or cache-loader.

Eugh. No. This is where most people get overwhelmed and put TypeScript in the “too hard” basket. I don’t blame them.

The bright sunny days (with Babel 7).

Wouldn’t it be nice to have one JavaScript compiler? Whether your code has ES2015 features, JSX, TypeScript, or something crazy custom — the compiler knows what to do.


I just described Babel. Cheeky.

By allowing Babel to act as the single compiler, there’s no need to manage, configure, or merge two compilers with some convoluted Webpack sorcery.

It also simplifies the entire JavaScript ecosystem. Instead of linters, test runners, build systems, and boilerplates supporting different compilers, they just need to support Babel. You then configure Babel to handle your specific needs. Say goodbye to ts-nodets-jestts-karmacreate-react-app-typescript, etc, and use the Babel support instead. Support for Babel is everywhere, checkout the Babel setup page:

Babel has you covered.

3) It’s faster to compile.

Warning! You might want to sit down for this bit.


How does Babel handle TypeScript code? It removes it.

Yep, it strips out all the TypeScript, turns it into “regular” JavaScript, and continues on its merry way.

This sounds ridiculous, but this approach has two strong advantages.

The first advantage: ️⚡️ IT’S LIGHTNING FAST ⚡️.

Most Typescript developers experience slow compilation times during development / watch mode. You’re coding away, you save a file, and… then… here it comes… annnnd… finally, you see your change. Oops, made a typo, fix that, save it, annnnd… eugh. It’s just slow enough to be annoying and break your momentum.

It’s hard to blame the TypeScript compiler, it’s doing a lot of work. It’s scanning for type definition files (*.d.ts), including within node_modules, and ensuring your code is used correctly. This is why many fork the Typescript type checking into a separate process. However the Babel + TypeScript combo still provides faster compilation thanks to Babel’s superior caching and single-file emit architecture.

So, if Babel strips out TypeScript code, what’s the point in writing TypeScript? That brings us to the second advantage…

4) Stay in the zone as you code.

You’re hacking some code together, quickly bashing out a solution to see if your idea has legs. You save the file, and TypeScript screams at you:


“No! I won’t compile this! Your code is broken in 42 different files!”

Yeah, you know it’s broken. You’ve probably broken a few unit tests too. But you’re just experimenting at this point. It’s infuriating to continuously ensure all your code is type safe all the time.

This is the second advantage of Babel stripping out TypeScript code during compilation. You write code, you save, and it compiles (very quickly) withoutchecking for type safety. Keep experimenting with your solution until you’re ready to check the code for errors. This workflow keeps you in the zone as you’re coding.

So how do you check for type errors? Add a npm run check-types script that invokes the TypeScript compiler. I tweak my npm test command to first check types, and then continue running unit tests.

It’s not a perfect marriage.

According to the announcement post, there are four TypeScript features that do not compile in Babel due to its single-file emit architecture.


Don’t worry, it ain’t so bad. And TypeScript will warn against these issues when the isolatedModules flag is enabled.

1) Namespaces.

Solution: don’t use them! They’re outdated. Use the industry standard ES6 modules (import / export) instead. The recommended tslint rules ensure namespaces are not used.

2) Casting a type with the <newtype>x syntax.

Solution: Use x as newtype instead.

3) Enums that span multiple declarations (i.e. enum merging).

I’m not sure what this is. I have searched online for “enum merging” and found nothing. Can anyone help? Please let me know in the comments!

4) Legacy-style import / export syntax.

Examples: import foo = require(...) and export = foo.

In all my years of TypeScriptin’ I’ve never come across this. Who codes this way? Stop it!

Ok, I’m ready to try TypeScript with Babel!


Let’s do this! It should only take about 10 minutes.

I’m assuming you have Babel 7 setup. If not, see the Babel Migration Guide.

1) Rename .js files to .ts

Assuming your files are in /src:

find src -name "*.js" -exec sh -c 'mv "$0" "${0%.js}.ts"' {} \;

2) Add TypeScript to Babel

A few dependencies:

npm install --save-dev @babel/preset-typescript @babel/plugin-proposal-class-properties @babel/plugin-proposal-object-rest-spread

In your Babel config file (.babelrc or babel.config.js):

{
    "presets": [
        "@babel/typescript"
    ],
    "plugins": [
        "@babel/proposal-class-properties",
        "@babel/proposal-object-rest-spread"
    ]
}

TypeScript has a couple of extra features which Babel needs to know about (via those two plugins listed above).

Babel looks for .js files by default, and sadly this is not configurable within the Babel config file.

If you use Babel CLI, add --extensions '.ts'

If you use Webpack, add 'ts' to resolve.extensions array.

3) Add ‘check-types’ command

In package.json:

"scripts": {
  "check-types": "tsc"
}

This command simply invokes the TypeScript compiler (tsc).

Where does tsc come from? We need to install TypeScript:

npm install --save-dev typescript

To configure TypeScript (and tsc), we need a tsconfig.json file in the root directory:

{
  "compilerOptions": {
    // Target latest version of ECMAScript.
    "target": "esnext",
    // Search under node_modules for non-relative imports.
    "moduleResolution": "node",
    // Process & infer types from .js files.
    "allowJs": true,
    // Don't emit; allow Babel to transform files.
    "noEmit": true,
    // Enable strictest settings like strictNullChecks & noImplicitAny.
    "strict": true,
    // Disallow features that require cross-file information for emit.
    "isolatedModules": true,
    // Import non-ES modules as default imports.
    "esModuleInterop": true
  },
  "include": [
    "src"
  ]
}

Done.

Well, the setup is done. Now run npm run check-types (watch mode: npm run check-types -- --watch) and ensure TypeScript is happy with your code. Chances are you’ll find a few bugs you didn’t know existed. This is a good thing! The Migrating from Javascript guide will help here.

Microsoft’s TypeScript-Babel-Starter guide contains additional setup instructions, including installing Babel from scratch, generating type definition (d.ts) files, and using it with React.

I’m using create-react-app.

It’s a little fiddly, but still possible! First, upgrade to create-react-app v2.0 (beta). Then setup react-app-rewired, which lets you override parts of the configuration. And finally, install this rewired plugin: react-app-rewire-typescript-babel-preset.


What about linting?

Use tslint.


npm install --save-dev tslint

Create a tslint.json file in the root directory:

{
  "defaultSeverity": "error",
  "extends": [
    "tslint:latest",
  ],
  "jsRules": {},
  "rules": {},
  "rulesDirectory": [],
  "linterOptions": {
    "exclude": ["**/node_modules/**"]
  }
}

Setup a lint command in package.json file:

"scripts": {
  "lint": "tslint '**/*.ts'"
}

That’s it! Now call npm run lint to lint your project. If you’re using VS Code, install the vscode-tslint extension for red squiggly lines.

If you use Prettier to automatically format your code, keep using it! It has built-in support for TypeScript files. Integrate with linting using tslint-config-prettier.

If you use React, you might enjoy some React rules provided by tslint-react.

Alternatively, you can keep eslint and use typescript-eslint-parser with eslint-plugin-typescript to add TypeScript rules. I haven’t tried this combination — please let me know in the comments if this works better than tslint.

There’s also the Google TypeScript style project which combines zero config linting and formatting (like Prettier, but uses clang-format). I haven’t tried this either, and would love to know your thoughts in the comments.

Babel + TypeScript = Beautiful Marriage.



Babel is the one-and-only JavaScript compiler you need. It can be configured to handle anything.

There’s no need to battle with two competing JavaScript compilers. Simplify your project configuration and take advantage of Babel’s amazing integration with linters, test runners, build systems, and boilerplates.

The Babel and TypeScript combo is lightning fast to compile, and allows you to stay in the zone as you code, and check types only when you’re ready.

Prediction: TypeScript will rise.

According to the most recent Stack Overflow Developer Survey, JavaScript is the most popular language, with TypeScript trailing at #12. This is still a great achievement for TypeScript, beating out Ruby, Swift, and Go.


I predict TypeScript will crack the top 10 by next year.

You can start with vanilla JavaScript and easily upgrade to TypeScript if you feel the need. The barrier to entry has been smashed thanks to Babel.

The TypeScript team are working hard to spread the love. This Babel preset was a year long collaboration, and they’ve contributed heavily to typescript-eslint-parser, which powers Prettier’s TypeScript support.

With the rise in popularity of VS Code, developers are already setup with an amazing TypeScript environment. Autocomplete on steroids will bring tears of joy.

It’s also likely to be integrated into create-react-app itself, thanks to support from Jared Palmer (creator of FormikRazzle, and Backpack). There’s a pending pull request, and if accepted will expose TypeScript to an audience of 200k downloads per month.

If you’ve been put off by TypeScript because it’s difficult to setup, it’s no longer an excuse. It’s time to give it a go.

It’s impossible to keep up with JavaScript.

You’re catching up every chance you get. Scrolling… reading… refreshing… skimming. You’re lost in 42 browser tabs of articles, tutorials, and GitHub repos. You bookmark a handful to check out later (or, never).


Originally published by Matt Turnbull  at  medium.com

===========================================

Thanks for reading :heart: If you liked this post, share it with all of your programming buddies! Follow me on Facebook | Twitter

Learn More

☞ Svelte.js - The Complete Guide

☞ The Complete JavaScript Course 2019: Build Real Projects!

☞ Become a JavaScript developer - Learn (React, Node,Angular)

☞ JavaScript: Understanding the Weird Parts

☞ JavaScript: Coding Challenges Bootcamp - 2019

☞ The Complete Node.js Developer Course (3rd Edition)

☞ Angular & NodeJS - The MEAN Stack Guide

☞ NodeJS - The Complete Guide (incl. MVC, REST APIs, GraphQL)

☞ Node.js Absolute Beginners Guide - Learn Node From Scratch



#javascript #reactjs #typescript

What is GEEK

Buddha Community

TypeScript with Babel: A Beautiful Marriage
Michael Bryan

Michael Bryan

1565161882

TypeScript with Babel: A Beautiful Marriage

Originally published by Matt Turnbull  at  medium.com

Discover four reasons why TypeScript and Babel are a perfect pair, and follow a step-by-step guide to upgrade your project with TypeScript in 10 minutes.

Huh? What? Why?

I didn’t understand the need for this new preset at first.


Aren’t Babel and TypeScript two completely different things? How can Babel handle the TypeScript type checking? TypeScript can already output to ES5 just like Babel can, so what’s the point? Isn’t merging Babel and TypeScript complicating things?

After hours of research, my conclusion:

TypeScript and Babel are a beautiful marriage.

Let me show you.

1) You already use Babel (or should).

You’re in one of these three categories:


  1. You already use Babel. If not directly, then your Webpack config feeds *.js files into Babel (this is the case for most boilerplates, including create-react-app).
  2. You use Typescript without Babel. Consider adding Babel to your arsenal, it provides many unique features. Read on.
  3. You don’t use Babel? It’s time to jump on board.

Write modern JavaScript without breaking anything.

Your JavaScript code needs to run in an old browser? No problem, Babel converts the code and makes everything a-okay. Use the latest and greatest features without worry.


The TypeScript compiler has a similar feature, enabled by setting target to something like "ES5" or "ES6". But the Babel configuration improves on this with babel-preset-env. Instead of locking in a specific set of JavaScript features (ES5, ES6, etc), you list the environments you need to support:

"targets": {
    "browsers": ["last 2 versions", "safari >= 7"],
    "node": "6.10"
}

Babel uses compat-table to check which JavaScript features to convert and polyfill for those specific target environments.

Take a moment to appreciate the genius who named this project ‘compat-table’.

An interesting technique used by create-react-app: compile with the latest browsers during development (for speed), and compile with a larger range of browsers in production (for compatibility). Nice.

Babel is super configurable.

Want React with JSX? Flow? TypeScript? The shiny new optional chainingproposal? Just install a plugin and let Babel handle it.


@babel/plugin-proposal-optional-chaining

There’s also a great selection of third-party Babel plugins. Using Styled Components? Improve server side rendering. Using Ramda? Easily compose functions. Want more? Manage feature flagsimprove lodash importsenhance console.log, or strip console.log. Whatever floats your boat, you’ll find it on this mega list: awesome-babel.

Better than console.log: babel-plugin-console

Macros!

You know Kent C Dodds? He’s created a game-changing Babel plugin: babel-plugin-macros.


Instead of adding plugins to your Babel config file, you import macros directly in your JavaScript code. At build time, the macro kicks in and modifies the code. Check out this post for more details.

I think Babel macros will explode this year. Not only is it an amazing concept, but it’s already integrated into create-react-app v2.0 (beta), which pushes the community support.

2) It’s easier to manage ONE compiler.

TypeScript requires it’s own compiler — it’s what provides the amazing type checking superpowers.


In the gloomy days (before Babel 7).

Chaining together two separate compilers (TypeScript and Babel) is no easy feat. The compilation flow becomes: TS > TS Compiler > JS > Babel > JS (again).


Webpack is often used to solve this problem. Tweak your Webpack config to feed *.ts into TypeScript, and then feed the result into Babel. But which TypeScript loader do you use? Two popular choices are ts-loader and awesome-typescript-loader. The README.md for awesome-typescript-loadermentions it might be slower for some workloads, and recommends ts-loaderwith HappyPack or thread-loader. The README.md for ts-loader recommends combining with fork-ts-checker-webpack-pluginHappyPackthread-loader, and / or cache-loader.

Eugh. No. This is where most people get overwhelmed and put TypeScript in the “too hard” basket. I don’t blame them.

The bright sunny days (with Babel 7).

Wouldn’t it be nice to have one JavaScript compiler? Whether your code has ES2015 features, JSX, TypeScript, or something crazy custom — the compiler knows what to do.


I just described Babel. Cheeky.

By allowing Babel to act as the single compiler, there’s no need to manage, configure, or merge two compilers with some convoluted Webpack sorcery.

It also simplifies the entire JavaScript ecosystem. Instead of linters, test runners, build systems, and boilerplates supporting different compilers, they just need to support Babel. You then configure Babel to handle your specific needs. Say goodbye to ts-nodets-jestts-karmacreate-react-app-typescript, etc, and use the Babel support instead. Support for Babel is everywhere, checkout the Babel setup page:

Babel has you covered.

3) It’s faster to compile.

Warning! You might want to sit down for this bit.


How does Babel handle TypeScript code? It removes it.

Yep, it strips out all the TypeScript, turns it into “regular” JavaScript, and continues on its merry way.

This sounds ridiculous, but this approach has two strong advantages.

The first advantage: ️⚡️ IT’S LIGHTNING FAST ⚡️.

Most Typescript developers experience slow compilation times during development / watch mode. You’re coding away, you save a file, and… then… here it comes… annnnd… finally, you see your change. Oops, made a typo, fix that, save it, annnnd… eugh. It’s just slow enough to be annoying and break your momentum.

It’s hard to blame the TypeScript compiler, it’s doing a lot of work. It’s scanning for type definition files (*.d.ts), including within node_modules, and ensuring your code is used correctly. This is why many fork the Typescript type checking into a separate process. However the Babel + TypeScript combo still provides faster compilation thanks to Babel’s superior caching and single-file emit architecture.

So, if Babel strips out TypeScript code, what’s the point in writing TypeScript? That brings us to the second advantage…

4) Stay in the zone as you code.

You’re hacking some code together, quickly bashing out a solution to see if your idea has legs. You save the file, and TypeScript screams at you:


“No! I won’t compile this! Your code is broken in 42 different files!”

Yeah, you know it’s broken. You’ve probably broken a few unit tests too. But you’re just experimenting at this point. It’s infuriating to continuously ensure all your code is type safe all the time.

This is the second advantage of Babel stripping out TypeScript code during compilation. You write code, you save, and it compiles (very quickly) withoutchecking for type safety. Keep experimenting with your solution until you’re ready to check the code for errors. This workflow keeps you in the zone as you’re coding.

So how do you check for type errors? Add a npm run check-types script that invokes the TypeScript compiler. I tweak my npm test command to first check types, and then continue running unit tests.

It’s not a perfect marriage.

According to the announcement post, there are four TypeScript features that do not compile in Babel due to its single-file emit architecture.


Don’t worry, it ain’t so bad. And TypeScript will warn against these issues when the isolatedModules flag is enabled.

1) Namespaces.

Solution: don’t use them! They’re outdated. Use the industry standard ES6 modules (import / export) instead. The recommended tslint rules ensure namespaces are not used.

2) Casting a type with the <newtype>x syntax.

Solution: Use x as newtype instead.

3) Enums that span multiple declarations (i.e. enum merging).

I’m not sure what this is. I have searched online for “enum merging” and found nothing. Can anyone help? Please let me know in the comments!

4) Legacy-style import / export syntax.

Examples: import foo = require(...) and export = foo.

In all my years of TypeScriptin’ I’ve never come across this. Who codes this way? Stop it!

Ok, I’m ready to try TypeScript with Babel!


Let’s do this! It should only take about 10 minutes.

I’m assuming you have Babel 7 setup. If not, see the Babel Migration Guide.

1) Rename .js files to .ts

Assuming your files are in /src:

find src -name "*.js" -exec sh -c 'mv "$0" "${0%.js}.ts"' {} \;

2) Add TypeScript to Babel

A few dependencies:

npm install --save-dev @babel/preset-typescript @babel/plugin-proposal-class-properties @babel/plugin-proposal-object-rest-spread

In your Babel config file (.babelrc or babel.config.js):

{
    "presets": [
        "@babel/typescript"
    ],
    "plugins": [
        "@babel/proposal-class-properties",
        "@babel/proposal-object-rest-spread"
    ]
}

TypeScript has a couple of extra features which Babel needs to know about (via those two plugins listed above).

Babel looks for .js files by default, and sadly this is not configurable within the Babel config file.

If you use Babel CLI, add --extensions '.ts'

If you use Webpack, add 'ts' to resolve.extensions array.

3) Add ‘check-types’ command

In package.json:

"scripts": {
  "check-types": "tsc"
}

This command simply invokes the TypeScript compiler (tsc).

Where does tsc come from? We need to install TypeScript:

npm install --save-dev typescript

To configure TypeScript (and tsc), we need a tsconfig.json file in the root directory:

{
  "compilerOptions": {
    // Target latest version of ECMAScript.
    "target": "esnext",
    // Search under node_modules for non-relative imports.
    "moduleResolution": "node",
    // Process & infer types from .js files.
    "allowJs": true,
    // Don't emit; allow Babel to transform files.
    "noEmit": true,
    // Enable strictest settings like strictNullChecks & noImplicitAny.
    "strict": true,
    // Disallow features that require cross-file information for emit.
    "isolatedModules": true,
    // Import non-ES modules as default imports.
    "esModuleInterop": true
  },
  "include": [
    "src"
  ]
}

Done.

Well, the setup is done. Now run npm run check-types (watch mode: npm run check-types -- --watch) and ensure TypeScript is happy with your code. Chances are you’ll find a few bugs you didn’t know existed. This is a good thing! The Migrating from Javascript guide will help here.

Microsoft’s TypeScript-Babel-Starter guide contains additional setup instructions, including installing Babel from scratch, generating type definition (d.ts) files, and using it with React.

I’m using create-react-app.

It’s a little fiddly, but still possible! First, upgrade to create-react-app v2.0 (beta). Then setup react-app-rewired, which lets you override parts of the configuration. And finally, install this rewired plugin: react-app-rewire-typescript-babel-preset.


What about linting?

Use tslint.


npm install --save-dev tslint

Create a tslint.json file in the root directory:

{
  "defaultSeverity": "error",
  "extends": [
    "tslint:latest",
  ],
  "jsRules": {},
  "rules": {},
  "rulesDirectory": [],
  "linterOptions": {
    "exclude": ["**/node_modules/**"]
  }
}

Setup a lint command in package.json file:

"scripts": {
  "lint": "tslint '**/*.ts'"
}

That’s it! Now call npm run lint to lint your project. If you’re using VS Code, install the vscode-tslint extension for red squiggly lines.

If you use Prettier to automatically format your code, keep using it! It has built-in support for TypeScript files. Integrate with linting using tslint-config-prettier.

If you use React, you might enjoy some React rules provided by tslint-react.

Alternatively, you can keep eslint and use typescript-eslint-parser with eslint-plugin-typescript to add TypeScript rules. I haven’t tried this combination — please let me know in the comments if this works better than tslint.

There’s also the Google TypeScript style project which combines zero config linting and formatting (like Prettier, but uses clang-format). I haven’t tried this either, and would love to know your thoughts in the comments.

Babel + TypeScript = Beautiful Marriage.



Babel is the one-and-only JavaScript compiler you need. It can be configured to handle anything.

There’s no need to battle with two competing JavaScript compilers. Simplify your project configuration and take advantage of Babel’s amazing integration with linters, test runners, build systems, and boilerplates.

The Babel and TypeScript combo is lightning fast to compile, and allows you to stay in the zone as you code, and check types only when you’re ready.

Prediction: TypeScript will rise.

According to the most recent Stack Overflow Developer Survey, JavaScript is the most popular language, with TypeScript trailing at #12. This is still a great achievement for TypeScript, beating out Ruby, Swift, and Go.


I predict TypeScript will crack the top 10 by next year.

You can start with vanilla JavaScript and easily upgrade to TypeScript if you feel the need. The barrier to entry has been smashed thanks to Babel.

The TypeScript team are working hard to spread the love. This Babel preset was a year long collaboration, and they’ve contributed heavily to typescript-eslint-parser, which powers Prettier’s TypeScript support.

With the rise in popularity of VS Code, developers are already setup with an amazing TypeScript environment. Autocomplete on steroids will bring tears of joy.

It’s also likely to be integrated into create-react-app itself, thanks to support from Jared Palmer (creator of FormikRazzle, and Backpack). There’s a pending pull request, and if accepted will expose TypeScript to an audience of 200k downloads per month.

If you’ve been put off by TypeScript because it’s difficult to setup, it’s no longer an excuse. It’s time to give it a go.

It’s impossible to keep up with JavaScript.

You’re catching up every chance you get. Scrolling… reading… refreshing… skimming. You’re lost in 42 browser tabs of articles, tutorials, and GitHub repos. You bookmark a handful to check out later (or, never).


Originally published by Matt Turnbull  at  medium.com

===========================================

Thanks for reading :heart: If you liked this post, share it with all of your programming buddies! Follow me on Facebook | Twitter

Learn More

☞ Svelte.js - The Complete Guide

☞ The Complete JavaScript Course 2019: Build Real Projects!

☞ Become a JavaScript developer - Learn (React, Node,Angular)

☞ JavaScript: Understanding the Weird Parts

☞ JavaScript: Coding Challenges Bootcamp - 2019

☞ The Complete Node.js Developer Course (3rd Edition)

☞ Angular & NodeJS - The MEAN Stack Guide

☞ NodeJS - The Complete Guide (incl. MVC, REST APIs, GraphQL)

☞ Node.js Absolute Beginners Guide - Learn Node From Scratch



#javascript #reactjs #typescript

Best Beauty Salon App Development Company

Do you want to build a superior beauty salon mobile app for your business? Then AppClues Infotech is a professional mobile app development company that works with a hair salon, Spa, and other businesses in the beauty industry.

Being the premier beauty salon mobile app development company we render quality solutions by making use of innovative thoughts. Our accomplished techies are adept at designing the feasible solutions that are affordable and cost-effective.

For more info:
Call: +1-978-309-9910
Email: info@appcluesinfotech.com

#how to build a mobile app for beauty salon #beauty salon app development company #best beauty salon app development company #top beauty salon app development company #create a beauty salon mobile app

Hayden Kerr

Hayden Kerr

1581238860

Building a React component with TypeScript, Babel and Parcel

Learn how to build a simple standalone React componen with TypeScript, Babel and Parcel.

#reactjs #react-js #typescript #babel #parcel

2020 Settings of React TypeScript Project with webpack and Babel

With create-react-app, you can properly and super easily setup a React TypeScript project. But what if you predict your application becomes big? You would face many problems. For example, you need multiple entry points, you have some node_modules which need to be transpiled to ES5.
In such situation, it’s better to walk with webpack and Babel from the beginning. I know they are something that software engineers don’t want to touch because it’s not application code. It’s just a bundle config. On the other hand, if you understand it, it means that you acquired one more skill !
So let’s learn bundling config step by step from scratch.

#webpack #babel #react #typescript #front-end-development

Aida  Stamm

Aida Stamm

1603095362

Babel 7.12.0 Released with TypeScript 4.1 Beta Support and More

We just published a new minor version of Babel!

This release includes support for the new TypeScript 4.1 beta features: template literal types and key remapping in mapped types.

Additionally, we implemented two new ECMAScript proposals: class static blocks and imports and exports with string names.

Lastly, we renamed @babel/plugin-syntax-module-attributes (and the corresponding parser plugin moduleAttributes) to @babel/plugin-syntax-import-assertions (and importAssertions), to match the recent proposal updates. The old plugin will work until Babel 8, but it’s deprecated now.

You can read the whole changelog on GitHub.

If you or your company want to support Babel and the evolution of JavaScript, but aren’t sure how, you can donate to us on our Open Collective and, better yet, work with us on the implementation of new ECMAScript proposals directly! As a volunteer-driven project, we rely on the community’s support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you’d like to discuss more!

Highlights

TypeScript 4.1 (#12129, #12131)

TypeScript 4.1 beta was announced a few weeks ago, and it includes new syntax features for types.

Template literal types allow concatenating strings at the type-level, using the template literal syntax:

type Events = "Click" | "Focus";

type Handler = {
  [K in `on${Events}`]: Function
};

const handler: Handler = {
    onClick() {}, // Ok
    onFocus() {}, // Ok
    onHover() {}, // Error!
};

Together with key remapping in mapped types, they can be used to represent complex object transformations:

type Getters<T> = {
    [K in keyof T as `get${Capitalize<K>}`]: () => T[K]
};

interface Dog { name: string; age: number; }

const lazyDog: Getters<Dog> = /* ... */;
lazyDog.getName(); // string
lazyDog.age; // error!

You can read more about TypeScript 4.1 in the release announcement, or check other examples of what capabilities these new features unlock. However, remember that TypeScript 4.1 is still experimental!

Class static blocks (#12079, #12143)

Example on Babel REPL

class C {
  static #x = 42;
  static y;
  static {
    try {
      this.y = doSomethingWith(this.#x);
    } catch {
      this.y = "unknown";
    }
  }
}

This stage 2 proposal allows you to apply additional static initializations when a class definition is evaluated. It is not intended to replace static fields but to enable new use cases that could not be accomplished before. In the example above, the static property y is initialized using #x. If doSomethingWith(this.#x) throws, y will be assigned by a default value "unknown".

You can read more about it in the proposal’s description.

Thanks to Jùnliàng, you can test this proposal by installing the @babel/plugin-proposal-class-static-block plugin and adding it to your Babel config. Since it is likely you’re already using other class feature plugins, be sure to place this plugin before the others:

{
  "plugins": [
    "@babel/plugin-proposal-class-static-block",
    "@babel/plugin-proposal-class-properties"
  ]
}

ℹ️ Babel implements an updated version of spec, which addresses feedback we have provided based on the current spec.

Imports and exports with string names (#12091)

Consensus was achieved during the last TC39 meeting with a PR to allow strings as the name of imported and exported variables:

// emojis.js
let happy = "wooo!";
export { happy as "😃" };

// main.js
import { "😃" as smile } from "./emojis.js";
console.log(smile); // wooo!

This allows using any valid UTF-16 name across modules, making JavaScript fully compatible with other languages such as WebAssembly.

You can enable parsing support for this feature by adding @babel/plugin-syntax-module-string-names to your configuration:

// babel.config.json
{
  "presets:" ["@babel/preset-env"],
  "plugins": [
    "@babel/syntax-module-string-names"
  ]
}

This feature will be enabled by default as soon as the syntax is merged into the main ECMAScript specification.

Please note that it’s not possible to transpile arbitrary strings to ES2015-style imports and exports: they will only be transpiled when targeting a different modules system such as CommonJS.

Import assertions parsing (#12139)

The “module attributes” proposal has been significantly changed and also renamed to “import assertions”.

We’ve implemented parsing support for this new version of the proposal, which can be enabled using the @babel/plugin-syntax-import-assertions plugin (or, if you are directly using @babel/parser, importAssertions):

 {
   "plugins": [
-    ["@babel/syntax-module-attributes", { "version": "may-2020" }]
+    "@babel/syntax-import-assertions"
   ]
 }

The most significant syntax changes are that the with keyword has been replaced with assert and assertions are now wrapped in curly braces:

import json from "./foo.json" assert { type: "json" };

import("foo.json", { assert: { type: "json" } });

You can read more about these changes in the proposal’s README.

⚠️ @babel/plugin-syntax-module-attributes will continue working until we release Babel 8.0.0, but will no longer be maintained, so we highly recommended migrating to the new plugin.

#babel #typescript #javascript #web-development #developer