哈哈，正如我所说，我正在将它用于其他用途，我不能就这样放弃它。更改端口肯定不难（似乎是句不祥之语）。
1 个赞
建议您在链接的主题上询问，从我简要查看该脚本来看，它似乎是硬编码的，但可能错了，该脚本可能是内置的。
我也注意到了硬编码的内容，但也有对 yml 文件中的端口配置以及环境变量的引用。我现在要放弃了。我已经投入了太多时间来测试我想要的东西。
我启动了一个带有全新 Ubuntu 22.04 的虚拟机。开发安装失败：Install Discourse for development using Docker - #213 by nordize
今天运气不好……但肯定不是几分钟能搞定的（无意冒犯）。感谢你的时间，也很抱歉浪费了你的时间。
1 个赞
@merefield 快速问一下：在容器中获取插件代码更新有没有比执行 d/shutdown_dev; d/boot_dev 更快的方法？这个方法耗时很久，并且会下载大量数据来拉取 docker 镜像。每次修改一行代码并在浏览器中测试时都这样做，即使是在 docker 化环境中也显得小题大做。
使用 d/rails s 重启 rails 服务器看不到我的插件代码更改。
这只需要在你移除或添加插件时进行，而不是在更改代码行时。
如果该行是 Ruby 或 CSS，它将热加载新代码。如果是 Ruby，你应该会看到终端中的 unicorns 正在重启，我记得是这样。
如果是 JavaScript，你只需要刷新浏览器。
我应该提到我的插件在符号链接中，并且除非你执行 d/shutdown_dev; d/boot_dev（指南中也提到了这一点），否则任何更改都不会反映出来，但我希望通过 Docker 本身可以找到解决方法，因为这些应该只是映射的文件。我可能会在另一个线程中询问，或者看看是否可以对其进行修改作为一种解决方法（或者不使用符号链接）。
这听起来不对。服务器进程就像在非 Docker 安装中一样重新启动。符号链接应该没有区别，并且是合适的工作方式。我不知道为什么你的行为不是这样……
好吧，请随意尝试。如果重启 Rails 和 Ember 就能解决问题，我早就发帖了。正如我刚才所说，指南也指出了这一点。
根据指南，只有在更改插件的集合（例如，通过删除或添加有效的符号链接）时，才需要运行这些重启命令。否则，Rails 应该会检测到代码更改并重新启动其进程。在配置中关闭此行为是可能的，但这应该是默认设置。
以下是自动重启的示例，尽管是在非 Docker 的开发安装上，但行为应该相似：
[DEV]: 编辑了未自动加载的文件。正在重启服务器...
- plugins/discourse-multilingual/extensions/post.rb
正在重启 UNICORN
I, [2022-06-15T13:25:29.082415 #227981] INFO -- : reaped #<Process::Status: pid 228047 exit 0> worker=0
I, [2022-06-15T13:25:29.082642 #227981] INFO -- : reaped #<Process::Status: pid 228048 exit 0> worker=1
I, [2022-06-15T13:25:29.082788 #227981] INFO -- : reaped #<Process::Status: pid 228049 exit 0> worker=2
I, [2022-06-15T13:25:29.082877 #227981] INFO -- : master complete
I, [2022-06-15T13:25:29.947587 #228661] INFO -- : Refreshing Gem list
收到 TERM 信号
正在关闭
正在终止空闲线程
Scheduler exiting...
暂停以允许作业完成...
再见！
正在启动 CSS 更改监视器
I, [2022-06-15T13:25:38.326511 #228661] INFO -- : listening on addr=0.0.0.0:3000 fd=25
我编辑了 post.rb 文件并保存，其余都是自动完成的。
抱歉，我现在无法访问我的 Docker 开发机器，因此无法确认 Docker 安装上也是如此，但我记得除非有更改，否则情况就是这样。
我没有编造，你知道的 
而且如果被告知应该可以工作，我也无能为力 我严格按照该指南在新 VM 安装了 Ubuntu 22.04。\n- 将插件符号链接到 discourse/plugins/ 子文件夹并更改插件中的 JS 代码，除非我执行 d/shutdown_dev; d/boot_dev，否则不会看到更改，尽管我重启了 d/rails s 和 d/ember-cli\n- 将插件复制到 discourse/plugins/ 子文件夹并更改插件中的 JS 代码，会看到更改，而无需执行 d/shutdown_dev; d/boot_dev，只需重启 d/rails s 和 d/ember-cli\n\n欢迎尝试以上方法。所讨论的插件是 discourse-math，更改 assets/initializers/javascript/*.js 中的代码（请记住，这些特定的插件文件是侧载的，并且浏览器不会直接 GET 调用它们；不确定这是否有区别，我还没有深入研究 Discourse 的内部工作原理）。\n\n附注：我知道我需要刷新浏览器（绕过缓存）……给我点信任。
正如马儿所说：
所以问题可能出在你本地，或者当前构建中出现了回归，但后者似乎不太可能。
我放弃了，你赢了。如果你自己尝试一下，请告诉我。
我当然不是在“争输赢”，但我们必须达到一个基本理解：
- 后端代码更改后，它应该自动重启。
d/shutdown_dev; d/boot_dev应该 只 在更改插件集合时才需要，而不仅仅是代码的个别行。
这应该会减少你需要排查问题的地方。
我刚刚 git pull 并尝试了一个更改，它重启了，所以这不是构建回归。
对我来说更奇怪的是，作为一个 docker 设置，实际上更难无意中覆盖打包的行为，所以它应该 更 可靠。
我回家后会在我的 docker 构建上尝试一下。
我理解目前这在工作流程上令人沮丧和恼火，这肯定会让我感到沮丧和恼火。
如果你已经完全清除了缓存，我不知道此时还能建议什么。
请注意，initializers 只在你第一次打开页面时运行一次。所以服务器进程重启是无关紧要的（并且只涵盖后端代码）。
我开发 Web 应用时，每次都会禁用缓存来运行开发者工具。我只是刚接触 Discourse 的代码和工具，并非刚接触（Web）开发。我在指南帖子里也发了一个问题。目前我只是复制了 discourse/plugins/ 下的插件目录，以避免麻烦。
1 个赞
我今天晚些时候会尝试类似的方法，然后汇报结果。
据我从浏览器调用中看到的，初始化程序 JS 中的 JS 代码是通过 eval()（每次打开页面时）从 discourse-math.js 进行侧加载的，这显然表明某些服务器端组件正在处理并缓存该初始化程序中的 JS 代码（也就是我正在更改的代码），因此需要触发那个特定的服务器端缓存程序来重新缓存它……如果插件是符号链接的，这不会发生，但如果是复制的，则会发生。
我对 Discourse 工具链不熟悉（而且由于时间不足，我当时也不想熟悉它）……因此我进行了逆向工程并提出了这些问题。
1 个赞
非 Docker 开发：
我刚才在初始化程序中尝试了这一点，无需重启任何进程，只需刷新浏览器即可识别 JavaScript 代码中的更改……这是非 Docker……我稍后会尝试一下
过了一会儿……
Docker 开发：
好的，现在我回到我的电脑上尝试了 Docker 解决方案，我进行了全新的安装，并且我看到了相同的行为：编辑初始化程序对我来说是有效的，服务器仍在运行，只需保存文件并刷新浏览器，无需重建容器。
所以行为相同
（我使用了 Discourse Locations 插件作为示例。）
你确定你的初始化程序没有问题吗？
鉴于重启后可以正常工作，是的，我很确定。为了100%可靠地重现，你可以尝试我提到的特定插件，在GUI中启用它并在GUI中选择Katex选项，然后编辑我提到的初始化器JS文件，然后在帖子中包含Latex代码；这个插件可能很特别，可能只在帖子包含Latex代码时才动态加载其JS初始化器（如果我设计Discourse的话，我会这样做）……但我并不指望你浪费时间来解决这个问题，我也不试图说服你我没有胡说八道
1 个赞
是的，说得有道理。
这真是非常非常奇怪。
我目前唯一的建议是切换到非 Docker 安装（不幸的是，这需要更长的时间来设置 
），看看效果如何？
最好能从团队那里获得一些关于你那里可能出错的输入。然而，Docker 解决方案肯定会降低这里出现不同行为的可能性，因为它被容器化并且是原子的 