ssr 抽离到单独仓库

[harttle]

SSR 只依赖 san 的开放接口和文档就能实现，理论上可以单独维护。在某些场景下需要 TypeScript 才能正确解析组件代码，因此需要一个支持 TypeScript 比较好的仓库，独立维护比较方便。这些场景包括：

1. 文件引用（便于代码组织）。如果 computed 内引用了另一个文件，需要解析 import 关系。
2. 生成其他语言的代码 SSR 代码。

考虑到其他语言的 SSR 无法支持 JS 特性全集，最终只能达到部分实现状态（不完美的 SSR），不应作官方支持。所以希望得到的目标状态：

• san-ssr 提供基本的代码生成框架，可插拔的代码生成器
• san-ssr 内置 JS 代码生成器（官方维护）

这个仓库是一个起点： baidu/san-ssr#1

[errorrik]

san ssr 在主仓库内，有一个逻辑是：当前版本生成的 ssr code，在浏览器环境下同版本的 san 能跑。毕竟会有 new feature 甚至是 breaking change。需要考虑这个逻辑。

[harttle]

假设 san 的发版遵循 semantic version。目前实现是 san-ssr 以 dependency 方式依赖 san；计划发版的原则是这样的：

1. 改为 san-ssr 以 peerDependency + caret range 方式依赖 san。考虑用 san-ssr 自己依赖另一个版本的 san 可能会造成困惑，因此要求有 ssr 需求的用户同时安装二者，只要安装成功就可以一起工作。
2. san-ssr 的版本号按照 san-ssr 自身的 bugfix、feature、breaking change 情况来迭代。
3. peerDependencies 中提升 san 版本的下限属于 breaking change。

下面举几个例子。考虑 san 的版本升级的情况：

1. bugfix、feature：caret range 仍然匹配。旧的 san-ssr 仍然可以和新的 san 一起用，不会 break，但可能少一些特性和bugfix。
2. breaking change：caret range 不匹配。san-ssr 需要升级并发包才允许和新的 san 一起使用。

[errorrik]

由于 zb 的原因

1. san 的 major 永远是 3
2. minor up 代表 breaking change，基本只会有一些小行为的不同
3. patch up 代表 bugfix 和 feature

建议：

1. major 和 minor 版本保持一致
2. peerDependencies 为同一 major.minor 下的最高版本

[Lohoyo]

由于 zb 的原因

zb = zhuang bi
请叫我雷锋。