1.JS的问题-类型错误

• 这个错误很大的原因就是因为JavaScript没有对我们传入的参数进行任何的限制，只能等到运行期间才发现这个错误；
• 并且当这个错误产生时，会影响后续代码的继续执行，也就是整个项目都因为一个小小的错误而深入崩溃；
• 写简单的demo的时候，很容易检查出来，但是开发大型项目，因为传入的参数问题，系统没办法运行。而且如果我们是调用别人的类库，又如何知道让我们传入的到底是什么样的参数呢？
  -如果我们可以给JavaScript加上很多限制，在开发中就可以很好的避免这样的问题了。

function foo(message) {
  console.log(message.length)

}
foo("hello world")//11
foo("你好啊，李银河")//7
//foo()//直接报错了 因为undified没有length属性

//如果下面还有成千上万行js代码要去执行的化，就不会执行了

//当前foo函数，在被其他地方进行调用的时候，没有做任何的参数校验
//1. 没有对类型进行校验， 只有字符串和数组才有length属性
//2. 没有对是否传入参数进行校验
//以上错误，意味着有一行有错误，底下的千千万万行代码都不会执行

2. 解决方法

如果我们可以给JavaScript加上很多限制，在开发中就可以很好的避免这样的问题了：

1. 比如我们的getLength函数中str是一个必传的类型，没有调用者没有传编译期间就会报错；
2. 比如我们要求它的必须是一个String类型，传入其他类型就直接报错；
3. 那么就可以知道很多的错误问题在编译期间就被发现，而不是等到运行时再去发现和修改；

3.认识TypeScript

1. JavaScript所拥有的特性，TypeScript全部都是支持的，并且它紧随ECMAScript的标准，所以ES6、ES7、ES8等新语法标准，它都是支持的；
2. 并且在语言层面上，不仅仅增加了类型约束，而且包括一些语法的扩展，比如枚举类型（Enum）、元组类型（Tuple）等；
3. 并且TypeScript最终会被编译成JavaScript代码，所以你并不需要担心它的兼容性问题，在编译时也不需要借助于Babel这样的工具；
4. 我们可以把TypeScript理解成更加强大的JavaScript，不仅让JavaScript更加安全，而且给它带来了诸多好用的好用特性；

4. TypeScript的编译环境

TypeScript最终会被编译成JavaScript来运行，所以我们需要搭建对应的环境： p我们需要在电脑上安装TypeScript，这样就可以通过TypeScript的Compiler将其编译成JavaScript；所以，我们需要先可以先进行全局的安装：

# 安装命令
npm install typescript -g
# 查看版本
tsc --version

//我们需要在电脑上安装TypeScript，这样就可以通过TypeScript的Compiler将其编译成JavaScript；
/* 

# 安装命令
npm install typescript -g
# 查看版本
tsc --version

要变已成js代码的化
就在当前文件夹下面运行
tsc 01_Hello_typescript.ts
就会生成js代码
tsc --init 生成tsconfig.json file
这个文件指定按照什么规则进行类型检验

*/


let message: string = "hello typescript"
//message = 123 写的时候就报错，完全不用编译，就是运行代码就知道它是错的
function foo(payload: string) {
  console.log(payload.length);
}
//foo()
foo("hello")
//foo(123)

//只要ts代码能运行，就说明编写的代码没问题，使用的时候都是按照规则使用的。
//忽略它报错的时候，就是不管他，就不会编译成功

export{}

5.其他运行方式

如果我们每次为了查看TypeScript代码的运行效果，都通过经过两个步骤的话就太繁琐了：
第一步：通过tsc编译TypeScript到JavaScript代码；
第二步：在浏览器或者Node环境下运行JavaScript代码；

以上问题可以通过以下两个方式解决
方式一：通过webpack，配置本地的TypeScript编译环境和开启一个本地服务，可以直接运行在浏览器上；
方式二：通过ts-node库，为TypeScript的运行提供执行环境；

5.1 方式一：webpack配置

https://mp.weixin.qq.com/s/wnL1l-ERjTDykWM76l4Ajw
大概：
创建一个文件夹
然后npm init
然后就有了packge.json
然后npm i webpack wabpack-cli -D
在目录下建webpack.config.js
然后配置webpack.config.js

const path = require('path')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  mode: "development",
  entry: "./src/main.ts",
  output: {
    path: path.resolve(__dirname, "./dist"),
    filename: "bundle.js"
  },
  devServer: {
  },
  resolve: {
    extensions: [".ts", ".js", ".cjs", ".json"]
  },
  module: {
    rules: [
      {
        test: /\.ts$/,
        loader: 'ts-loader'
      }
    ]
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: "./index.html"
    })
  ]
}

5.2 方式二：使用ts-node

步骤1：安装ts-node
npm install ts-node -g
步骤2：另外ts-node需要依赖 tslib 和 @types/node 两个包：
npm install tslib @types/node -g
步骤3：直接通过 ts-node 来运行TypeScript的代码：
ts-node math.ts

这样代码就直接跑在了node环境中，不需要编译成js了，因为ts-node帮我们做了两件事，一个是
编译成js，一个是让他跑在node上

const name: string = "abc"
const age: number = 18
console.log(name);
console.log(age);

export{}
/* 这是因为，同学们默认情况下，我们所有的这些TS文件，它都是在同一个作用域，

下面进行编译的就是你的这个文件里面，比如说有个name，对吧，在另外一个文件里面也有个name，
或者在我们整个的这个浏览器到环境下面某一个地方有这么一个name的时候，
那么这个name的名称它默认情况下会冲突的，那如果把每一个文件看成是一个单独的作用域的时候，
就是在我们最后的话，给他来个export{}，
这样写的话就表示这个文件是一个单独的作用，
就是你加上export的时候，就表示我这个是一个模块儿，
模块儿里面有自己的作用域，我自己作用域里面有自己的name和有自己的age，
不会和别人冲突，所以这是这个冲突解决的其中一个方案，
还有别的解决方案后面后面的话我们再说这样的话，
我们先这样解决，让我们在这里可以正常的去编写的代码，不让他报错。

*/

/* 


npm install ts-node -g

npm install tslib @types/node -g

ts-node ts-node 02_TypeScript的数据类型.ts
之后，控制台就直接打印出结果了。

*/

同学们ts-node的这个指令在执行的时候，它会默认情况下有一个我们ts-config.json文件的呢，因为它是一个全局安装的一个工具，那么它会根据我们全局安装的这个工具里面所配置的这个tsconfig.json来对我们的这个代码进行编译，编译完之后的话，再来对它做执行，所以它里面相当于就已经有我们tsconfig.json那些配置。