工作区插件和发布到npm的插件表现不同

[TomLBZ]

===================原问题=============================
发布到npm并通过插件市场安装的插件和工作区插件的表现似乎不同，疑似bug（不确定是为什么），向各位大佬求教。
复现步骤：

1. 创建一个koishi docker container。
2. 在container内按照README.md规定的步骤创建一个简单的工作区插件，编辑其代码形如：

import { Context, Schema, Session } from 'koishi';
export const name = '@foo/bar';
export interface Config {
  sname: string;
  irate: number;
}
export const Config: Schema<Config> = Schema.object({
  sname: Schema.string().default("test").required(),
  irate: Schema.number().max(1).min(0).default(0.25).required(),
});
function condition(session: Session, config: Config) {
  if (session.subtype === 'group') {
    if (session.parsed.appel) return true; // 测试情况1：机器人被at，回复
    if (session.content.includes(config.sname)) return true; // 测试情况2：机器人收到含“test”的消息，回复
    if (Math.random() < config.irate) return true; // 测试情况3：按0.25的概率随机回复
    return false // 默认情况：机器人不回复
  } else {
    return true; // 非群聊一律回复
  }
}
async function someAsyncFunc(session: Session, config: Config){
  let res = "";
  // ----------------------------
  //产生实际回复的异步逻辑，例如调用其他服务器上的后端API等等
  // ----------------------------
  return res;
}
export function apply(ctx: Context, config: Config) {
  ctx.middleware(async (session, next) => {
    if (condition(session, config)) { // 应当回复的情况
      return await someAsyncFunc(session, config); // 异步返回回复
    }
    return next();
  })
}

3. 作为工作区插件，在同一个container中测试1、2、3三种情况，记录结果。
4. 将插件发布到npm。
5. 创建新的koishi docker container，在新container中通过插件市场安装该插件，再测试1、2、3三种情况，记录结果。
6. 对比结果。
   =====================================
   预期结果：
   工作区插件与发布的插件表现相同。
   实际结果：
   插件作为工作区插件时，测试情况1、2、3均正常工作。
   但是如果将插件发布到npm，再用另一个koishi docker container从插件市场安装该插件，那么测试情况2和3将不再工作，只有情况1继续正常工作。
   请问这是怎么回事呢？该如何解决呢？

=======================编辑分割线=========================
补充信息：我的原问题对问题的理解有误，导致提问不合适。这里是补充信息：

1. 在"Ubuntu 22.04.1 LTS"（我的本地测试环境）上运行koishi docker container (koishijs/koishi:latest)，然后在container内安装插件运行，插件没有任何问题。这说明问题的本质并非“工作区插件和发布到npm的插件表现不同”。
2. 在"Debian GNU/Linux 11 (bullseye)"（我的服务器环境）上运行koishi docker container (koishijs/koishi:latest)，然后在container内安装插件运行，插件的条件判断出现问题，涉及到config的成员时判断便会失效。
3. 我之前提交这个QnA的时候没有说明系统环境的不同，所以导致无法复现。我自己测试的时候在本地测试环境也无法复现，只有在服务器中可以复现。这说明问题的本质有可能是“与config相关代码的兼容性”。
4. 见下面的代码，只有当涉及到config的成员的时候，才会出问题。
5. 我的一点猜想：config的底层实现的某些依赖是specific to某些linux版本的，然而docker container在Linux上natively运行的时候，这些依赖不同了。
6. 出问题的代码如下（已删除无关代码）：

function getReplyCondition(session: Session, config: Config){
  if (session.subtype === 'group') {
    if (session.parsed.appel) return 1; //测试情况1，正常工作
    if (session.content.includes(config.botname)) return 2; //测试情况2，在特定linux下不工作，怀疑是config的问题
    if (Math.random() < config.randomReplyFrequency) return 3; //测试情况3，在特定linux下不工作，怀疑是config的问题
    return 0;
  } else {
    return 4; //测试情况4，正常工作
  }
}

export function apply(ctx: Context, config: Config) {
  // write your plugin here
  ctx.middleware(async (session, next) => {
    let condition = getReplyCondition(session, config); // 判断条件分支
    if (condition > 0) {
      let logger = ctx.logger('testing');
      logger.info(`condition ${condition} met, replying`); // 打印当前的条件分支。在特定Linux下，2和3永远不会被输出。
      return await asyncDummyFunction(session, config); // 调用异步API
    }
    return next();
  })
}

很抱歉一开始的提问不太合适，还请各位大佬指教 m(_ _)m。

[shigma]

单独看你的描述无法确认问题是什么，需要复现。你能说说你发布的插件叫什么吗？

[TomLBZ]

补充信息：

1. 在"Ubuntu 22.04.1 LTS"（我的本地测试环境）上运行koishi docker container (koishijs/koishi:latest)，然后在container内安装插件运行，插件没有任何问题。
2. 在"Debian GNU/Linux 11 (bullseye)"（我的服务器环境）上运行koishi docker container (koishijs/koishi:latest)，然后在container内安装插件运行，插件的条件判断出现问题，涉及到config的成员时判断便会失效。
3. 我之前提交这个QnA的时候没有说明系统环境的不同，所以导致无法复现。我自己测试的时候在本地测试环境也无法复现，只有在服务器中可以复现。
4. 见下面的代码，只有当涉及到config的成员的时候，才会出问题。
5. 我的一点猜想：config的底层实现的某些依赖是specific to某些linux版本的，然而docker container在Linux上natively运行的时候，这些依赖不同了。
6. 出问题的代码如下（已删除无关代码）：

function getReplyCondition(session: Session, config: Config){
  if (session.subtype === 'group') {
    if (session.parsed.appel) return 1; //测试情况1，正常工作
    if (session.content.includes(config.botname)) return 2; //测试情况2，在特定linux下不工作，怀疑是config的问题
    if (Math.random() < config.randomReplyFrequency) return 3; //测试情况3，在特定linux下不工作，怀疑是config的问题
    return 0;
  } else {
    return 4; //测试情况4，正常工作
  }
}

export function apply(ctx: Context, config: Config) {
  // write your plugin here
  ctx.middleware(async (session, next) => {
    let condition = getReplyCondition(session, config); // 判断条件分支
    if (condition > 0) {
      let logger = ctx.logger('testing');
      logger.info(`condition ${condition} met, replying`); // 打印当前的条件分支
      return await asyncDummyFunction(session, config); // 调用异步API
    }
    return next();
  })
}

[TomLBZ]

单独看你的描述无法确认问题是什么，需要复现。你能说说你发布的插件叫什么吗？

我把原描述的例子发布成了插件 koishi-plugin-koishi-test ，专门用来复现这个问题。用 koishijs/koishi:latest 镜像在 Ubuntu 22.04.1 LTS 上安装这个插件所有分支都能进入，但在 Debian GNU/Linux 11 (bullseye) 上分支2、3均无法进入。

[simon300000]

或者把按照例子能复现出问题的container/详细步骤脚本上传上来？

[TomLBZ]

我在原QnA描述下面补充了有关复现的信息。我自己尝试用同一个镜像（koishijs/koishi:latest）在本地的Ubuntu 22.04.1 LTS上无法复现，但在服务器的Debian GNU/Linux 11 (bullseye)上可以复现。因此问题的本质应该并非我一开始误以为的“工作区插件和发布到npm的插件表现不同”，而有可能是“与config相关代码的兼容性”。但我也不明白为什么同一个镜像会表现不同。