1.运行npm run d后提示:Error: listen EADDRINUSE:address already in use 0.0.0.0:8090(注:你的端口不一定是8090)
**原因:**有进程已经占用端口8090,需要杀死该进程或者在代码中手动修改端口
解决:
1.1 杀死进程
步骤1:ps aux | grep node得到进程ID,一般是第一个数字(或者netstat –nao | findstr 8090)
步骤2:kill -9 PID (或者在cmd中执行:taskkill/F /pid xxx)
2.2 手动修改端口配置
在我的项目中端口配置是写在server.js文件中的,搜索8090,将8090改成8091(或者其他端口),再次运行(npm run d)即可
2. 运行npm run d / npm run build(或其他npm命令)之后报错cross-env不是内部命令
解决:
(1)删除node_modules、package-lock.json (rm -rf /node_modules package-lock.json)
(2)清除npm缓存:npm cache clean –force
(3)重新安装包:npm install
复制代码
再次运行,成功!
3. 使用npm安装依赖包时,--save-dev和--save有什么区别呢?
(1)--save-dev:可以简写为-D,这个会自动把模块版本号添加到package.json中的devDependencies部分(只用于开发环境的安装包);
(2)--save可以简写为-S,这个会自动把模块版本号添加到package.json中的dependencies部分(要打包到生产环境的安装包时使用)。
复制代码
更多请查看npm文档:docs.npmjs.com/cli/install
4.在使用Vue+Typescript(或者React+Typescript)的开发模式中,出现报错提示:Type 'Object' is not generic
解决:使用inetrface替代。我的处理方式是将需要使用的对象定义到一个文件中export出来使用,如下:
declare module 'CommonObj'
{ export interface UseItem
{
[key: string]: string;
}
}
复制代码
这样定义完成之后,就可以在要使用的地方import进来,定义的时候用:
itemOnject: UseItem = {};
复制代码
就不会再提示上面的错误了。
5.typescript报错:Property 'xxx' does not exist on type 'xxx'解决
这是在刚开始使用typescript时最常遇到的问题。因为我们习惯了js+vue的写法,props里面的字段(如item)就不会再次进行定义而直接用this.item取值,这个时候typescript就会提示上面的错误。
最简单的解决方式就是:在该文件中,在export default class xxx extend Vue{}中再次定义该值,如:
export default class xxx extend Vue{
item:itemObj;
}
复制代码
这个使用使用this.item就不会再产生提示了。
@Component({
components:{},
props: {
item: {
type: Object,
default: () => {},
}
}
})
interface itemObj { memberName: string; memberNo: string; id?: string;}export default class xxx extend Vue{
item:itemObj;
get showItemVal() {
console.log(this.item); // 或者直接使用this.$props.item也可以避免出现这个提示(实际上这样更简洁)
}
}
复制代码
6. 在vue+typescript的开发模式中,遇到$refs的使用报错
报错内容基本上都是Property 'xxx' does not exist on type 'Vue | Element | Vue[] | Element[]'这种形式。这个时候只需要将$refs定义成如下形式,再次使用就不会报错了。
举例:
报错位置形式为:
getFormData() {
this.$refs.formDetail.getFormData();
}
复制代码
改为:
$refs: {
formDetail: HTMLFormElement,
}
复制代码
之前报错的位置不用再修改。
7. 想让自己的commit变得清晰有条理吗?
从上面的图中可以看出来,我一共提交了12次,但是实际上我这里主要的目的是开发一个新的功能;那么,按照正常的流程来讲,开发一个新功能的过程是:(先假设我们前端拿到这个开发任务的时候后端的接口还未提供)
-
1. 前端开始写页面(不联调),页面写完之后进行一次提交:commit1; 2. 原型设计有变动,页面与之对齐更新,进行一次提交:commit2; 3. 这个时候接口提供了,接口联调,联调完成后提交:commit3; 4. 基本的工作都完成了,开始自验证,自验证之后修改并提交:commit4。 复制代码
也就是说,一次完整的开发过程,大概只需要4次提交,为什么我会有12次commit呢,这是个悲伤的故事。因为在每次我认为已经完成了提交完之后,又发现了需要修改的地方,久而久之也就出现了12次之多。那么我们如何将这么多次的commit记录变得清爽呢,下面正式开始:
1: git log查看提交记录
2:假设此时你需要合并最近3次的提交
git rebase -i HEAD~3, 这个时候就会出现如下界面,这个时候,认真读一读里面的内容,它告诉你,你要保留那个commit就使用pick,否则就使用squash (将后面的commit合入到前几次一起)
那我们就按照它的提示来修改(将pick改成squash即可,要输入需要先按一下键盘上的“i”,表示输入,修改完成之后按Esc+":"+wq保存退出),会出现下面的界面,也就是让你修改commit的提交信息,删除(双击dd)不需要的行,保留需要的提示即可,要重新输入点击i就可以了。操作成功之后会显示Successfully这样的提示信息。如果报错了也不要方,直接取消就可以了:git rebase --abort
3: 将压缩后的commit再次提交就可以大功告成了。
git push -f (加-f的目的是因为我们合并的历史记录已经在远程仓库之前了,你无法覆盖它,所以需要强制执行这个操作)
再次到git库区看看我的提交记录,如下所示已经变成10次了。
7. 启动前端项目时出现NODE_ENV既不是内部或外部命令,也不是可运行的程序
严格来说,这其实不算错误,知识Win和Mac的环境变量设置方式不同。
PS: 这是在Windows系统才会出现的一种报错现象。需要安装cross-env (yarn add cross-env --save-dev / npm install cross-env --save-dev)
,安装完成之后再在package.json文件中,对应有NODE_ENV的前面加上cross-env即可解决。
持续更新中......