不管是Vue.js源码，还是UI组件库Element-plus，只要有多人协同开发，代码规范上多多少少都会有一些"百花齐放"。即使像Vue.js源码，不同开发者在命名上也会附带个人风格。

很多人在用 `localStorage` 的时候喜欢直接用，明文存储，直接将信息暴露在；浏览器中，虽然一般场景下都能应付得了且简单粗暴，但特殊需求情况下就不行了，该学学封装提升下逼格了！

分享常见的表单校验与比较少见的表单校验方式，可能是全网较少去介绍表单检验方式的文章喔，内含源码与在线 Demo。旨在帮助遇到相同问题的开发者快速解决该类问题

不是标题党，这是一位leader在一次代码评审会对小组成员发出的“怒吼”，原因是在代码评审中发现很多地方还是采用ES5的写法，也不是说用ES5写法不行，会有BUG，只是造成代码量增多，可读性变差而已。

工欲善其事，必先利其器 前言 有时候我想看别人提交的代码改了什么东西，结果他们改了个小东西，保存的时候把整个文件按照他本地规则格式化了...我￥%&#@ 需求 所以我想要一套好的代码规范，代码格式化，

本篇文章讲怎么在前端团队快速制定并落地代码规范!!!\ 干货，拿走这个[仓库](https://github.com/jd-antelope/s-lint)

前言 1.1 开篇 代码错误检查和自动格式化对于我们来说都不陌生，它往往陪伴着我们的每一行代码输出、每一次保存提交，我们享受着自动格式化带来的便利，但偶尔也有些小问题影响体验。 比如，面对同一个项目，

前端工程化，很多人一听到这个词，想到的就是 `webpack`；基于现在的环境，这种想法不能说它是错的，但也不是很对，毕竟前端工程化的概念比 `webpack` 要大的多。

Eslint + Prettier + stylelint + Husky + Lint-staged Reference Link: eslint-config-prettier stylelint