elpis框架抽离并发布 SDK-NPM 包

为什么要抽离 sdk-npm

将 Elpis 基础框架功能封装成 npm 包，可以在客制化项目中直接引用，实现业务代码与基础架构的分离。这种方式不仅有利于项目结构的清晰化，还支持灵活的功能扩展，例如 middleware 中间件、extend 扩展、service 扩展等，显著提升了代码的复用性和可维护性。

那么，这样做又有什么好处呢？

简单的总结为3点：解耦、可拓展、可复用。

解耦业务和基础架构：通过 SDK-NPM 包的形式，业务方只需关注自身的业务逻辑，而基础框架的维护与扩展由开发团队负责。
灵活扩展：业务方可以根据需求灵活地扩展中间件、服务等功能，而无需关心基础框架的具体实现。
共享与复用：基础功能一旦封装为 NPM 包，可以在多个项目间复用，避免重复开发。

本地调试 npm 包

本地调试 npm 包是开发过程中常用的操作，本文使用的是 npm link 软链接方式，具体步骤如下：

将 Elpis 项目中执行 npm link, 将 elpis 软链接到全局 node_modules。
在 elpis-demo 项目中执行 npm link elpis，引入刚刚创建的软链接包。
注意：若在 elpis-demo 中重新执行 npm install，链接会失效，需重新执行 npm link 操作。

elpis 改造点

入口改造

需要通过导出的方式，提供给外部使用

js 复制代码

// 引入 elpis-core
const ElpisCore = require("./elpis-core");

module.exports = {
  /**
   * 启动 elpis
   * @params options 项目配置，透传到 elpis-core
   */
  serverStart(options = {}) {
    const app = ElpisCore.start(options);
    return app;
  }
}

在 elpis-demo 项目中引入方式如下： elpis-demo 引入

js 复制代码

const { serverStart } = require("@linzisong/elpis");

// 启动 elpis 服务
const app = serverStart({
  name: "ElpisDemo",
  homePage: "/view/project-list",
});

elpis-core 适配改造

当 elpis-core 作为一个依赖包时，像 middleware 不仅需要读取依赖包中的所有 app/middleware/**/**.js 下所有的文件,还需要支持业务代码 中的app/middleware/下所有文件目录,因此需要对 middleware 进行改造适配。改造代码如下：

js 复制代码

// middleware.js
// ...

module.exports = (app) => {
  const middlewares = {};
  // 读取 app/middleware/**/**.js  下所有的文件
  const elpisMiddlewarePath = path.resolve(__dirname, `..${sep}..${sep}app${sep}middleware`);
  const elpisFileList = glob.sync(
    path.resolve(elpisMiddlewarePath, `.${sep}**${sep}**.js`)
  );
  // 遍历app/middleware/下所有文件目录，把内容加载到 app.middleware
  elpisFileList.forEach((file) => {
    handlerFile(file);
  });

  // 读取  业务目录/app/middleware/**/**.js  下所有的文件
  const businessMiddlewarePath = path.resolve(app.businessPath, `.${sep}middleware`);
  const businessFileList = glob.sync(
    path.resolve(businessMiddlewarePath, `.${sep}**${sep}**.js`)
  );
  // 遍历业务代码文件目录，把内容加载到 app.middleware
  businessFileList.forEach((file) => {
    handlerFile(file);
  });

  function handlerFile(file) { /** 省略 */ }

  app.middlewares = middlewares;
};

其中 elpis 读取的 middlewares 文件目录和业务代码读取的 middlewares 文件目录存在差异，我们需要再 elpis-core 中获取业务文件路径 app.businessPath = path.resolve(app.baseDir, './app'); 。同样的 routerSchema、controller、service、extend也是做类似的操作，而 config 则修改为业务代码的配置覆盖 elpis-core 的配置。

Webpack 改造

将 Webpack 配置以函数形式导出，便于业务项目自定义。例如在 webpack.dev.js 和 webpack.prod.js 中使用： ···js module.exports = () => { return { // 具体配置 }; }; ··· 同时，将 webpack.base.js 中的路径改为相对路径，第三方依赖使用 require.resolve() 方式引入，以提高兼容性和可移植性。

发布上线

发布 npm 包前需完成以下几项准备工作：

版本管理 ：遵循语义化版本规范（SemVer），根据改动类型（新功能、修复、破坏性变更）更新 package.json 中的版本号。
注册与登录 ：如未注册 npm 账号，需先进行注册，并在终端执行 npm login 进行登录。
构建编译 ：执行 npm run build 确保代码编译为可发布形态。
发布命令 ：在项目根目录运行 npm publish，即可将包发布到 npm 仓库。

如需发布为公开包，需确保 package.json 中未设置 "private": true。若需发布到私有仓库，则应在 publishConfig 中指定 registry。

发布完成后，建议在业务项目中通过 npm install @linzisong/elpis 安装并使用，并可通过版本号控制更新策略。

总结

通过将 Elpis 基础框架功能封装为 npm 包，可以实现业务代码与基础架构的解耦，并提供了灵活的扩展机制。通过本地调试、适配改造和 Webpack 配置暴露等改进，我们实现了 SDK 的高效开发和使用。最终，通过规范化的发布流程和持续的版本维护，确保了 SDK 的稳定性和可持续发展。这种抽离 SDK 的方式，为日常开发提供了更高的效率和更好的灵活性，尤其在大规模业务场景中，能够大大提高开发效率和系统稳定性。

学习资源：抖音-哲玄前端大全栈实践课