FishHawk
FishHawk
700行两眼一黑，先把web/src/domain/crawlers拆出来单独合并吧，再是后端API，再是前后端对接
分开合并是很正常的，不是说一个feature就必须端到端合并，不如说限制pr大小是惯例了，不管是公司还是开源项目。分开合并的意义，是减少review的负担。现在根本没有testcase，但如果要写的话，我上面说的三个拆分，每个都可以写testcase
拆pr就是为了review，700行代码神仙来了也难受。没事，我来拆吧，我可以测。
我觉得显式隐式都可以加。 显式：epub在目录上，txt在标题下，加一行“※ 本内容为机器翻译”。 隐式：epub在meta里面也加一个元素。 web小说文件可以搞，文库和本地在epub解析升级前不好搞。 @kurikomoe 你有兴趣搞web吗？
> 这部分不是在后端生成 epub/txt 阶段做的么？（我只看过文库那边） 是后端，我意思是web小说的后端文件
> ※ 翻译来自绿站 署名于情于理都不合适 > 因为我想以后做一个像绿站的一样的阅读器，奇数和偶数行的颜色深浅不一样。 想做TXT阅读器吗？支持复杂预设格式的TXT阅读器不是好思路，吃力不讨好，做个TXT转EPUB可能更好点。 另外即使没有这行，TXT也不是奇偶稳定对应的，因为空行不会x2。
> 很多功能不一定要完整部署auth，感觉还是加回来好，要不然每次得手动改 这个其实做一半被打断了，会给auth加个调试模式，让本地调试环境可以登录的
文库的ui我其实有点不满意，出版社不该放那里的。 哔哩轻小说的UI设计得很好： 
已知问题，谷歌要强推他的阉割版M3插件标准。目前暂时不影响正常使用。这个issue不关闭，留着记录这个问题的处理进度。
all作为特殊的收藏夹id，列表页面的一些操作可能需要特殊处理