帮朋友上线一个软装设计的搭建工作区
setup遇到的问题
这个项目是以fabric为基础，通过对素材的canvas对象进行操作，并绑定用户交互来实现的设计师编辑器。除了里面用到了fabircjs, canvas, ‘node-sass’等
依赖，canvas的安装在不同os下安装情况可能不尽相同，这里以我常用的macos为例进行记录一下我遇到的几个问题。
canvas
依赖了canvas，而canvas在gyp时又依赖了pkg-config套件，这在macOS下是不默认安装的，报错中会有如下信息：
./util/has_lib.sh: line 31: pkg-config: command not found
通过brew install pkg-config安装依赖可以解决。
在这之后继续yarn或者npm install大概率出现cairo找不到的错误，这是一个C语言实现的偏底层的2D矢量绘图库，报错信息如下：
Package cairo was not found in the pkg-config search path.
Perhaps you should add the directory containing `cairo.pc'
to the PKG_CONFIG_PATH environment variable
No package 'cairo' found
gyp: Call to './util/has_lib.sh freetype' returned exit status 0 while in binding.gyp. while trying to load binding.gyp
通过brew install cairo安装依赖可以结局。
node-sass
两个点主要一下：
一个是这个包在国内可能拉不到，如何切换镜像源这里就不再赘述。
另外一个是node-sass是可以build fresh package的，在install时通过postinstall的hook触发gyp，
这里一个有意思的现象（我没再次验证）是如果某个工程第一次build失败，在没有rm掉node_modules的情况下只继续install，
好像不会触发新的build，所以直接跑工程会遭遇到sass编译失败。而node-sass在node12版本下是有严重的兼容性问题的，
这里我直接切到了node8上进行rebuild，npm rebuild node-sass，然后编译通过，报错和通过截图如下：
extract
观察要代理的html资源（因为是远程协助，对方是svn仓库= =b，也没有做容器化），发现工程启动后的本地资源于线上资源有不少差异，如下图：
而本地资源只有一个app.js, 没有将css进行单独打包，如下图：
extract是vue cli中css对象的一个选项，将应用的css单独抽离出来，放在一个单独文件，这里缺少了。
在生产模式下打包，extract默认是true，在dev mode默认是false
Default: true in production, false in development
由于我们的代理资源需求，这里设置为true，再次打包后，我们发现css单独抽离了，如下图：
chunk-vendors
对比目标html，我们发现还缺少了chunk-vendors，这其实是webpack的codespliting，将业务code于依赖code拆分打包。
这么做的好处是可以针对性缓存，因为我们的业务代码是经常迭代更新的，而业务代码所依赖的三方库并不会经常变动，而vue在打包时会sum结果的hash，
单独打包后的依赖可以在客户端缓存使用很久，业务代码会根据hash来准确更新，这样就提高了加载速度。这些chunk-vendors本质上
是打包的node_modules文件夹下的依赖，当然这是可以定制的，从名字到要打包的三方库都可以自由定制。在这里我们其实并不需要
将chunk-vendors打包出来，因为理论上本地依赖于线上依赖是相同的，只是我们都打在了一起；直接代理这个大包也是可以正确启动开发的，
这里为了减少可能的坑，也进行一致化。
主要利用了webpack的一个魔法注解webpackChunkName，而这个注视又依赖于动态依赖注入：
@import( /* webpackChunkName */'@vue/component/xx' );
而发现工程的babel也没了。。。vue可以直接设置.babelrc，也可以通过官方文档所推荐的babel.config.js来指定。
在bable中使用@vue/babel-preset-app的预设, 这样就可以对动态引入正确编译。修改后打包结果如下：
代理
我们可以用vue的代理api来做劫持，但这只对一个工程生效，我个人有时候多个PC工程并行开发，倾向于一个可以全局管理的地方。
这里我用的是xswitch，一个浏览器插件来做资源劫持。
可以为不同项目添加不同的rules，并且可以勾选哪些rules生效，支持正则和通配，因为用时间久了就继续采用。
除了上述问题外，在setup阶段，基本就没什么坑了。
