介绍
vue23 组件库
# 前提
之前在做一个vue指令库的时候，写的是v3版本的，我当时希望看一下这玩意儿能不能在vue2环境下跑。当时觉得这个需求比较常见，应该有现成的解决方案，很快就找到了vue demi，额，实际上，这玩意儿只能解决一部分问题，在一些vue的工具库里，它确实有用，也就是它可以让我指令库在vue2 3中分别依赖对应的vue。或者说，它只是在代码层上实现了兼容，也就是同一份业务代码，可以放在不同环境下跑，但它没有提供v2.v3同时存在且可切换的环境，而一个vue项目调试肯定是需要这个东西的
# 分析
我们先分析下问题出在哪里，vuedemi做了什么，以及为啥一些现有的项目没有遇到这种情况。 v2v3有几个区别，一是多出了composition api，而这个东西，在vue3中，这个东西是内置的，但在vue2中，是外置的，vue demi通过postinstall，根据当前包的版本，动态生成入口，使其恒为内置 二是模板编译不同，sfc的转换不同，一些库能避免这个点的原因是其使用了jsx或者vnode的写法，没有sfc。 更麻烦的是，在打包工具中，至少在vite中，那个转化sfc的插件(无论v2,v3)，它会自己跑到vue的包里去找转化采取的方法，这才是真正致命的地方，因为想要同时存在两个版本的vue，显然需要使用别名安装，那它自然是找不到的，如果手动 去输入compiler，在vue2的sfc插件中没有手动输入的入口（所以以vue2主包会简单一丢丢）
# 进一步分析
上面两个点，其实应该理解为三个层面，一是api层面，也就是一般包版本更迭的问题（尤其是major级别更新，）要么api名字变了，要么功能变了，要么多了或者少了。二是配套插件层面，比如sfc解析，或者说，setup语法解析，这两类其实都不难，在vite中用模式，给出两套配置就行，特定的api，难的在第三个点，即node_modules的冲突问题，有些库它依赖xx的路径是写死的，这就会有破坏性的效果
其实最好的方法,是直接Monorepo，然后隔离两个环境去搞，应该会简单一些，但这样代码是两个库里各有一套？还是放在哪个地方共用？可以琢磨一下