乐趣区

关于前后端分离:前后端未分离项目禁用ES6方案

jiezi

背景

近半年，已产生几起 FM 我的项目（FreeMarker我的项目）在 IE 浏览器或者 360 浏览器兼容模式环境下运行出错的线上问题，导致业务流程无奈执行上来。尽管始终在强调开发同学在做 FM 我的项目的需要时不要应用 ES6，然而口头上的团队约定约束性力度无限，加上开发同学早已习惯性应用ES6，使之问题层出不穷，另外，还有些Web Apis 和款式在 IE 上存在兼容性问题（比方：Element.scrollIntoView()、Element.scrollTo()），这些 API 和款式的应用也须要强制禁用，因而亟需用工具在编程阶段束缚。

因应用 ES6 或者应用兼容性较差的 Web Apis 导致的缺点：

因应用 ES6 或者应用兼容性较差的 Web Apis 导致的线上问题（都是三级事件）：

另外，因 jira 单备注不够清晰，款式兼容性导致的问题未作统计。

计划

上面计划只针对 JavaScript 脚本应用 ES6+ 语法个性的解决，对于兼容性较差的 Web Apis 以及款式的解决另作计划。

Babel 转译

在 webpack 中引入 babel 将ES6语法转译成ES5，然而在构建之前须要将源文件做如下革新：

var managePage = {};

function  debounc() {}

革新后：

window.managePage = {}

window.debounc =  function  debounc() {}

为什么不设置 libraryTarget: 'window' 以全局变量输入？

因为 libraryTarget: 'window' 的打包形式只能将 export 导出的对象以全局对象的形式输入，但在将源代码进行如下革新后，线上不会有问题，在本地启动我的项目会报 “xxx is not defined”，因为export 包裹后的变量会变成了局部变量。

export var managePage = {};

export function  debounc() {}

计划的长处：

  • 任何 JavaScript 高级语法个性都能很好的反对；
  • 能够对代码做压缩、混同解决，减小文件大小，进步动态文件加载性能，进步源代码安全性；

计划的毛病：

  • 在构建之前须要对源文件进行革新，工作量比拟大，容易出错；
  • 须要引入构建工具，增加构建配置，批改 Jenkinsfile CI 脚本；

ESlint 正告

ESlint是一款插件化的 javascript 代码检测工具，咱们能够利用其在 FM 我的项目脚本中是否应用了 ES6+ 语法，如果脚本中有应用，立刻报错解决，并提醒哪些关键字的应用属于 ES6 语法。另外，为避免开发同学强推应用了 ES6+ 语法的代码，在 git hooks 的pre-commit钩子中执行 eslint 命令校验，若通过，则代码胜利commit；若不通过，控制台会打印谬误日志。

留神：请开发同学在 commit 时不要增加 --no-verify 参数，否则会跳过校验

具体落地流程：

（1）在 VScode 编辑器中装置 ESlint 拓展插件，并启用

（2）在我的项目根目录下手动或者执行 npx eslint --init 创立 .eslintrc.json 配置文件，并增加如下配置项：

{
  "root": true,
  "env": {
    "browser": true,
    "jquery": true
  },
  "parserOptions": {
      "ecmaVersion": 5,
      "sourceType": "script"
  },
  "rules": {}}

（3）因为管理中心不须要反对 IE，因而对于此端的脚本不须要 ESlint 检视，咱们在根目录下创立 .eslintignore 配置文件，向其中增加须要跳过检视的文件门路，比方 src/main/webapp/static/js/adjustPage.js 不须要检视：

// .eslintignore
src/main/webapp/static/js/adjustPage.js

（4）在根目录执行 npm init 生成 package.json，并增加如下命令，当执行git commit 提交代码之前会执行 precommit 钩子进行 eslint 校验

{
  "scripts": {"precommit": "eslint --ignore-path .gitignore"}
}

留神：如果这一步配置没有失效，能够试着引入 husky 解决

该计划的长处：

  • 配置比较简单，不必革新脚本代码，不必批改 Jenkinsfile CI 脚本；

该计划的毛病：

  • 源代码间接在控制台能看到，不平安；

综上所述，如果已有项目组在 FM 我的项目中曾经引入构建工具，比方备货组的商城页面曾经引入多种语言开发，再应用构建工具打包，此类我的项目中沿用第一种计划即可，其余场景下的 FM 我的项目能够抉择应用第二种计划，具体场景具体分析。

组织施行

暂定打算：上述计划的落地由 XX 同学领头，Aston55迭代在询报价组试行，如果成果比拟好，则 Aston56 迭代在备货组、商家服务组推广，进而在整个平台推广。

问题反馈与倡议

所有应用问题或者更好的倡议都能够向 XX 同学反馈，谢谢反对与配合！

退出移动版