@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 现在就是网页版的

@codermagefox 公司项目还是谨慎一点比较好。毕竟不同人不断迭代下肯定会出现很多奇奇怪怪的 magic，如果是个人项目能够控制全局，我觉得还是可以考虑实际根据情况尝试一下的。

@love 几个月前我也试过。也是一堆问题，改了改源码也没法解决差太多了，就没继续搞。最近重新弄了一下发现还是有点盼头的。虽然遇到一堆问题但是基本上都解决或者找到替代方案。

做大动作前一定要分分支，这样万一搞不成直接扔了就好了

@codermagefox parcel 本质没有太大的变化，反而少了 webpack 的大量配置带来的优势与劣势。

我换 snowpack 目的是为了提升开发体验。我现在按一次保存按钮电脑十几秒不能动 ide 也没有提示。算是比较有目的性的。

生产环境还是会使用 webpack 进行代码的优化与编排。目前尚没有到可以完全替换的地步

@felixin 有的。可以选择 babel 插件的 ts 模块或者 typescript 插件(只能二选一)

使用 typescript 插件的的话其实就是后台运行一个 tsc 的 watch 模式

@huayumo 最早的聊天机器人 Eliza