起因一直以来，我都是直接在浏览器Tampermonkey扩展页面直接新建用户脚本来开发的：对于一些简单的脚本，这没有什么问题，即改即看。但当代码多了以后问题就来了，自带编辑器开发体验确实不太舒服，没有格式化，没有代码补全，无法模块化编写代码等等，这时候我就想寻找一个打包方案，让我们可以在自己的编辑器如VSCode里开发，这样就可以充分利用前端工程化的便利，提升开发体验。常见的打包工具比如webpack、parcel、rollup等，首先排除webpack（笑），然后试了下parcel，效果不太理想，之后试了rollup感觉还可以。转眼想到要用vue开发，那就直接上vite吧?，vite也是用r
起因一直以来，我都是直接在浏览器Tampermonkey扩展页面直接新建用户脚本来开发的：对于一些简单的脚本，这没有什么问题，即改即看。但当代码多了以后问题就来了，自带编辑器开发体验确实不太舒服，没有格式化，没有代码补全，无法模块化编写代码等等，这时候我就想寻找一个打包方案，让我们可以在自己的编辑器如VSCode里开发，这样就可以充分利用前端工程化的便利，提升开发体验。常见的打包工具比如webpack、parcel、rollup等，首先排除webpack（笑），然后试了下parcel，效果不太理想，之后试了rollup感觉还可以。转眼想到要用vue开发，那就直接上vite吧?，vite也是用r
这里给大家分享我在网上总结出来的一些知识，希望对大家有所帮助业务背景近些年来，随着前端工程架构发展，使得前端项目中也能拥有如后端工程的模块能力。正所谓“能力（越）越大（来），责任（越）越大（卷）”，现在的前端工程不仅仅要满足业务需求，还伴随更多复杂的环境适配问题，例如：1.api请求的域名会根据不同环境而不同；2.线上环境和测试环境在打包策略有所不同「如线上要隔离sourceMap、屏蔽vue|reactdevtools等...」；3.前端spa组件根据不同环境做出不同逻辑；老板恨不得把所有应用端都收归到一个项目里面，什么微前端、uniapp多端方案接踵而至。。。但无论是什么方案，都离不开一个
这里给大家分享我在网上总结出来的一些知识，希望对大家有所帮助业务背景近些年来，随着前端工程架构发展，使得前端项目中也能拥有如后端工程的模块能力。正所谓“能力（越）越大（来），责任（越）越大（卷）”，现在的前端工程不仅仅要满足业务需求，还伴随更多复杂的环境适配问题，例如：1.api请求的域名会根据不同环境而不同；2.线上环境和测试环境在打包策略有所不同「如线上要隔离sourceMap、屏蔽vue|reactdevtools等...」；3.前端spa组件根据不同环境做出不同逻辑；老板恨不得把所有应用端都收归到一个项目里面，什么微前端、uniapp多端方案接踵而至。。。但无论是什么方案，都离不开一个
本文记录如何在Vue2环境下尽量使用Vue3的Composition-api并配合Vuetify2使用前言之前在改造一个用Vuetify2的项目，由于Vuetify3还处于beta阶段并且与Vuetify2相比缺失一些特性，但又想用Vue3的语法，于是寻找了下相关方案，下面简单记录一下。开始之前建议使用VSCode开发并安装以下插件且禁用Vetur：VueLanguageFeatures(Volar)TypeScriptVuePlugin(Volar)初始化使用npminit初始化项目添加所需依赖vue@2.6.14:指定2版本，不指定的话默认安装3版本vue-template-compile
本文记录如何在Vue2环境下尽量使用Vue3的Composition-api并配合Vuetify2使用前言之前在改造一个用Vuetify2的项目，由于Vuetify3还处于beta阶段并且与Vuetify2相比缺失一些特性，但又想用Vue3的语法，于是寻找了下相关方案，下面简单记录一下。开始之前建议使用VSCode开发并安装以下插件且禁用Vetur：VueLanguageFeatures(Volar)TypeScriptVuePlugin(Volar)初始化使用npminit初始化项目添加所需依赖vue@2.6.14:指定2版本，不指定的话默认安装3版本vue-template-compile
在《JS模块化》系列开篇中，曾提到前端技术的发展不断融入很多后端思想，形成前端的“四个现代化”：工程化、模块化、规范化、流程化。在该系列文章中已详细介绍了模块化的发展及四种模块化规范。本文简单聊聊规范化中的git规范。1规范化在企业级开发中，“一千个读者有一千个哈姆雷特”是很常见的事，每个程序员对技术的理解、视角和掌握程度参差不齐，导致编写的代码五花八门。规范化包括很多，我在企业实践中重点关注两个方面：代码规范和git提交规范。代码规范最基础的是代码格式，不同的代码格式虽然运行起来没有问题，但代码超级难看，代码乱七八糟、一堆warning，虽然不影响运行，但看着太恶心，就像下面的情形：估计是为
在《JS模块化》系列开篇中，曾提到前端技术的发展不断融入很多后端思想，形成前端的“四个现代化”：工程化、模块化、规范化、流程化。在该系列文章中已详细介绍了模块化的发展及四种模块化规范。本文简单聊聊规范化中的git规范。1规范化在企业级开发中，“一千个读者有一千个哈姆雷特”是很常见的事，每个程序员对技术的理解、视角和掌握程度参差不齐，导致编写的代码五花八门。规范化包括很多，我在企业实践中重点关注两个方面：代码规范和git提交规范。代码规范最基础的是代码格式，不同的代码格式虽然运行起来没有问题，但代码超级难看，代码乱七八糟、一堆warning，虽然不影响运行，但看着太恶心，就像下面的情形：估计是为
项目基本架构跟 vite实现element-plus按需配置，自定义主题和读取/修改系统主题色 相同。项目地址。目标：在vite-plugin-pages自动读取文件夹配置下，设置前端路由权限和单组件权限。权限模块后台返回数据假设：返回与前端文件夹匹配的路径数据，并包含权限信息。假设，无权限数据为：{"code":200,"data":[{"menu":[{"label":"面板1","key":"index","meta":{"isAdmin":false,"requiresAuth":false}},{"label":"统计分析","key":"index-analysis","meta"
项目基本架构跟 vite实现element-plus按需配置，自定义主题和读取/修改系统主题色 相同。项目地址。目标：在vite-plugin-pages自动读取文件夹配置下，设置前端路由权限和单组件权限。权限模块后台返回数据假设：返回与前端文件夹匹配的路径数据，并包含权限信息。假设，无权限数据为：{"code":200,"data":[{"menu":[{"label":"面板1","key":"index","meta":{"isAdmin":false,"requiresAuth":false}},{"label":"统计分析","key":"index-analysis","meta"
