star7th

网址npmmirror.com就是淘宝镜像。你可以尝试删除web_src/package-lock.json文件再安装看看

1，基于性价比考虑，暂未支持富文本编辑器。最主要是富文本带来的维护成本太高了，后面新增什么功能都要考虑兼容两种文本情况。而收益方面，showdoc目前以IT团队为核心，支持富文本的意义不大。如果有一天想扩展非IT群体，可能会支持富文本。 2，编辑多表格，用mardkown的表格是不太方便的。建议新建项目的时候，使用showdoc的表格类型项目。它实现了一个轻量级的在线excel。 3，附件方面的名字怕是不好改。首先，附件文件储存是用英文名的。如果读取出来的时候改回中文名，那么就需要把整个文件先读取进内存再输出。额外带来蛮多性能消耗。目前不是很想引入这种机制。 4，夜间模式短期内不做好。主要是showdoc的页面一直都是补丁式的增加，UI代码有历史包袱。要换主题的话需要大改。这个以后再说。 5，全局搜索功能是一个可以考虑的点吧。确实也会有性能问题的。不一定引入这个功能。 6，文章tab功能我个人觉得是重了点的。大多数人可能用不到但它却占据着视觉空间。如果能找到一种最小代价侵占视觉空间的交互方式再看吧。 7，编辑页面那个标题栏固定在顶部的功能后面看下，这个是有必要做的。 8，新版showdoc已经支持单文章导出。

如果你想订阅通知，你希望以哪种方式收到提醒？邮件？ jhsy 于2020年3月31日周二 下午3:26写道： > > - 增加项目依赖关系,或者接口依赖关系. > - 建议增加接口订阅机制 > - 建议增加接口变动通知提醒 > > — > You are receiving this because you are subscribed to this thread. >...

也就是说这个东西需要依赖到用户自己编程。这个怕是会增加用户复杂度而没什么人用 jhsy 于2020年3月31日周二 下午3:32写道： > 事实上订阅->通知的过程是为了解决项目繁杂. 接口繁多导致的信息不对称 > > 通知机制可以预留接口. > > - 邮件通知 > - 公司内的IM通知 > - 有条件的短信平台通知等等 > > — > You are receiving this because you...

这个会考虑一下吧。要收集下用户反馈。 另外那个项目依赖/接口依赖就不考虑了。showdoc是项目和项目之间是独立的。如果彼此有依赖情况，自己在文档里讲清楚即可。 jhsy 于2020年3月31日周二 下午3:42写道： > 怎么说呢. 信息不对称的代价我觉得是非常耗时和昂贵的. 如果能有提醒能最大化的减少这种影响, 那何乐而不为呢, 如果是我的话. > 我可能会将接口的状态做成"类生命周期"一样. 每个周期触发钩子. 钩子检测订阅的事件配置. 触发不同的动作. 比如 post 一个请求出去. > 携带变动的参数. 请求的URL可以配置. > 当然站内信的模式就无须触发这种钩子. > > 仅仅是建议供参考. > > —...

Showdoc supports plantuml, not mermaid

这个后面加上

目前还没有太明确的计划。可能一个月可能几个月。到时候都需要更新。

showdoc不鼓励你这种用法。要写多个接口文档，请善于使用showdoc本身的目录功能。你这样企图把整个项目都放在一个页面里是不合理的。合理情况下使用，右侧标题目录不会有那么多层级。

showdoc本身的目录功能支持无线层级，那个才是推荐用法。