@tomsun28 用 docker-swarm 的理由是需要的资源少。k8s 毕竟太大了，适合一个比较大的体量的集群。而我目前只有一台主服务器，主要是想用它的滚动升级。

适合的才是最好的。如果没有必要我觉得没必要跟风用 k8s 。

@XiLingHost 感谢你的建议。因为我是客户端编译好了全量丢到 oss 上的，这样就能享受 CDN 的加持，还没想过用 docker 部署。。。毕竟我的服务器只有 1m 小水管

@renmu123 是的。我觉得减少入门门槛非常重要。我写了一套简单的 DSL 来适应复杂的需求。然后发现其实很多人根本没法使用，哪怕最简单的只需要跟着示例复制黏贴即可。所以我现在正在实现一套布局编辑器以帮助用户使用

@jones2000 把你的项目 po 出来，大家一起学习呗

@dartabe 是的。之前我用 enzyme，然后它不维护了。。。现在转成 testing-library

@Kirsk 我不是很确定您对企业级的定位是什么。
我对企业级的定位是能持续迭代，有明确需求，有错误收集，日志收集，能集群化，有监控。那么这个项目就是一个完备的企业级项目。

@Braisdom 之前看到过您的项目，虽然不是很懂 java，但是 star 了，加油开源人！

@zone10 不好意思，一方面自己比较内向没有宣传，开发 3 年+前面 2 年多都是一个人在闷头开发，另一方面因为还在不断迭代，总感觉部署文档写了不久就要失效了的错觉。其实已经提供了 Dockerfile 文件和 docker-compose 配置，以及用于 docker-swarm 的配置和简单的教程。可能放在不明显的地方所以看不见吧。谢谢您的指出，我会花时间去考虑写一个比较正式一点的部署文档的。

关于账号问题，其实我没有办法考虑一个比较私人(指没有被邀请不能看到聊天记录)的聊天项目什么情况下可以允许匿名用户访问。可能是我个人的局限性吧

感谢你花时间的回复, 但仍要请教一下什么是一个集中化的思维。因为我目前没有协作者我不知道应该如何开始。期待您的回复

@CismonX 感谢指正。对 GPL 协议有点误解，已改正。谢谢您的指出

@keygen88 因为我的项目针对的跑团这个圈子本身就比较小。入门成本高，复杂度高，学习曲线陡峭。这些原因导致了真正的跑团用户并不是很多，另外我个人也不是很擅长宣传。多方面因素下导致这种情况是理所当然。

尽量找新小区，老小区没有固定车位停车困难。

支持一下

人闲就可以做到每日产出

受教了，发现我的博客也有一样的问题

个人博客 http://moonrailgun.com/

@hewelzei 这个不是行内 require 的问题，而是在 esmodule 中使用 commonjs 的语法引入了一个 json 内容的问题。

按照标准来说这种行为属于混用，统一使用 esmodule 或者统一使用 commonjs 都不会出现这个问题。

我觉得不支持标准行为属于正常操作。本质上来说内部的 rollup 没有处理这种情况，snowpack 自身也不会去处理，也就 webpack 这种大而全的会考虑方方面面兼容一切 case——这也是 webpack 显得臃肿的原因

@hewelzei
snowpack 内部通过 rollup 来实现打包。通过 commonjs-plugin 实现对 commonjs 格式的兼容

具体见: https://github.com/snowpackjs/snowpack/blob/d90a1fb8a080bfe32e7283d87063381cd97f48bb/esinstall/src/index.ts#L383-L387

不过实际使用过程中如果依赖使用了行内 require 会无法正常执行。我的实际 case 中遇到了两处。翻阅代码发现已经被修复了因此升级就解决了

@Tigerw 现在就是网页版的