coderwei的日常

什么是构建工具 vite相较于webpack的优势 vite脚手架和Vite vite启动项目 vite环境变量

Vue3的响应式原理(理论篇)

你所不知道的undefined 数组方法不完全指北

​ vite对css的配置都是在vite.config.js的css字段里面。他下面有四个字段，下面我们一一介绍。 css.module​ module字段主要是用于配置css模块化的行为，并且vite并不会拿着这个配置去做什么事情，我们在这里配置的东西，他会原封不动的交给postcss-modules，与其说在配置vite，不如说在配置postcss-modules。 localsConvention：主要配置对导出的模块化的key的处理（类名是否驼峰）。他有四个值 camelCase：默认值，类名将被骆驼化，原始类名不会删除 camelCaseOnly：类名将被骆驼化，原始类名会删除 dashes：只有类名中的破折号会被驼峰化，原始类名不会删除。我们正常写样式，类名都是用-分隔，而不会用_进行分割，这也是规范，这里也会用到 dashesOnly：类名中的破折号将被驼峰化，原始类名会删除 scopeBehaviour：主要用于配置模块化是全局还是局部，可以理解为是否开启模块化。默认是local，用了它之后，我们会发现模块化的css会携带一个hash，而我们就是依靠这 ...

​ vite对css的配置都是在vite.config.js的css字段里面。他下面有四个字段，下面我们一一介绍。 css.module​ module字段主要是用于配置css模块化的行为，并且vite并不会拿着这个配置去做什么事情，我们在这里配置的东西，他会原封不动的交给postcss-modules，与其说在配置vite，不如说在配置postcss-modules。 localsConvention：主要配置对导出的模块化的key的处理（类名是否驼峰）。他有四个值 camelCase：默认值，类名将被骆驼化，原始类名不会删除 camelCaseOnly：类名将被骆驼化，原始类名会删除 dashes：只有类名中的破折号会被驼峰化，原始类名不会删除。我们正常写样式，类名都是用-分隔，而不会用_进行分割，这也是规范，这里也会用到 dashesOnly：类名中的破折号将被驼峰化，原始类名会删除 scopeBehaviour：主要用于配置模块化是全局还是局部，可以理解为是否开启模块化。默认是local，用了它之后，我们会发现模块化的css会携带一个hash，而我们就是依靠这 ...

​ 大家会发现浏览器回去请求.vue文件，那么浏览器为什么能够识别.vue文件，vite在中间或者是说在把文件给到浏览器之前对文件做了什么事情，能够让浏览器识别、解析.vue文件？大家可以带着问题看下去。 开发服务器​ 我们在正常情况下，使用vite开发项目的时候，都会使用vite帮我们配置的服务器，通过pnpm run dev启动，浏览器发送的请求是给到vite启动的服务器，所以他可以在将文件发给浏览器之前做很多的事情。所以下面我们就搭建一个建议的vite服务器，看下vite都做了些什么？ 安装依赖​ vite搭建服务器主要使用的就是koa框架。所以我们的服务器也同样用koa来搭建。 引入koa1pnpm add koa 入口文件​ 我们新建一个index.js文件作为项目的入口文件，实现以下代码 12345678const koa = require("koa") //导入koa node端需要使用common jsconst app = new koa() // 实例化一个koaapp.listen(5173, () =>
...

区分开发or生产环境​ 在正常开发流程中，我们会有生产环境、测试环境、预生产环境等，每个公司有着自己不同的实践。但他们都逃不开一个测试环境和生产环境，所以说在vite我们怎么区分生产环境和测试环境，这点就尤为重要。在vite中我们区分环境也很简单，我们在vite.config.js文件可以将defineConfig函数中传入一个函数，他会接收一个参数，这个参数是一个对象，该对象下面有一个command参数是供我们区分生产和开发环境，他有两个值：serve或者build。 123456789import { defineConfig } from 'vite'export default defineConfig((config) => { console.log(config.command); // serve return { optimizeDeps: { exclude: [] } }}) ​ 当我们执行pnpm ru ...

初始化项目首先我们新建一个test-vite文件夹，作为项目根目录，然后新建几个文件 main.js：入口文件 123456789 // import { count } from './count' // 上面这种写法是有异常的，浏览器在找文件的时候，他需要的是一个完整的文件名，我们经常在vite/webpack环境下这样子写是因为这两个构建工具在编译的时候帮我们补全了路径，但是我们现在没有使用构建工具的时候需要自己补全路径 import { count } from './count.js' console.log(count);- count.js：抽离的count模块 ~~~javascript export const count = 1 index.html：项目启动文件 12345678910111213<!DOCTYPE html><html lang="en"> <head> <meta charset= ...

​ 在以前开发的时候，我们可以清晰的分开vue-cli和webpack，其实最主要的原因就是webpack是国外的，它有着单独的文档，而vue-cli属于vue团队的，他们是两个团队开发的不同的东西，所以我们对他们很敏感，分的也比较清，而且最新的vite，他们共属于vue，虽然是不同团队，但他们是同一个组织。包括vite文档，也有意弱化vite的存在感，他希望我们拿着就用，也是官网那句话开箱即用。 什么叫vite脚手架​ 在这里我们就不关注脚手架的概念了，我们把注意力集中在vite脚手架，官网再让我们创建一个vite项目的时候就是用的脚手架创建的 123npm create vite@latest #npmyarn create vite #yarnpnpm create vite #pnpm ​ 我们可以简单理解为，vite脚手架给我们创建的项目，是vite团队最佳实践的产物，使用脚手架创建的项目，给我们提供了一套预设，几乎满足我们绝大多数情况下的开发，不需要我们额外配置别的东西，还是那句话 开箱即用。 ​ 何为预设？举个通俗的 ...

现代开发中存在的问题​ 随着时代的进步，我们所开发的项目也不是以前能比的，借用vite官方的描述：当我们开始构建越来越大型的应用时，需要处理的 JavaScript 代码量也呈指数级增长。包含数千个模块的大型项目相当普遍。基于 JavaScript 开发的工具就会开始遇到性能瓶颈：通常需要很长时间（甚至是几分钟！）才能启动开发服务器，即使使用模块热替换（HMR），文件修改后的效果也需要几秒钟才能在浏览器中反映出来。如此循环往复，迟钝的反馈会极大地影响开发者的开发效率和幸福感。 这里说的JavaScript 开发的工具就是指的我们在上一章说讲的构建工具，一个快速的开发环境，会极大的提高我们的开发效率 天下苦webpack久矣​ 相信大家再用webpack开发的时候，明显感觉到，随着我们的项目迭代，webpack启动服务器所耗费的时间也随着提高，当然，或许这都能接受。但是当我们修改文件，虽然基于HMR（热更新），但是我们也会发现需要耗费几秒的时间，这极大影响我们的开发体验。而且这个时间会继续随着我们项目迭代更拉长，后面就更无法接受了。 webpack vs Vi ...