目录

1. 开发
2. 使用
3. 命令
4. 发布看这里!!!!!

1. stereov开发者环境配置

1. 设置内部npm源 npm set registry http://172.19.197.5:4873 yarn config set registry http://172.19.197.5:4873 如果内部源出问题了可以恢复到官方源
   • 淘宝源: https://registry.npmmirror.org/
   • npm源: https://registry.npmjs.org/
   • 或者直接指定源安装 比如npm install -g tsx --registry=https://registry.npmjs.org
2. 安装依赖 yarn install
3. 链接 执行yarn link 然后到examples文件夹下执行yarn link stereov
4. 启动 执行yarn dev

2. 与stereoMapVue联调

在stereov项目中执行yarn link 然后在stereoMap项目中执行yarn link stereov即可 这个操作会在node_modules中生成一个软链接(会覆盖点原有的node_modules/stereov文件夹) 如果stereMap的vite.config.ts中配置了如下的监听, 那么即可做到监听stereov项目的变化自动打包(当然stereoMap项目要启动yarn dev, stereov项目要启动yarn build-dev)

  server: {
    watch: {
      ignored: ['**/node_modules/!(stereov)/**'],
    }
  }

当我们不需要联调了 参考如下方式即可恢复到装包的方式 在stereoMap中执行yarn unlink stereov然后执行yarn install

3. 使用stereov

3.1 安装

npm set registry http://172.19.197.5:4873

yarn add [email protected]

3.2 宿主项目打包时的处理

要求宿主项目将stereov的包里面的*.bundle.js复制走

vite的配置

import { Plugin } from "vite";
import { fileURLToPath } from "node:url";
import { dirname, resolve } from "path";
import fs from "node:fs";
const __dirname = dirname(fileURLToPath(import.meta.url));
// 创建复制stereov资源的插件
function copyStereovAssetsPlugin(): Plugin {
  return {
    name: "copy-stereov-assets",
    enforce: "post",
    apply: "build", // 只在构建时应用
    async closeBundle() {
      const srcDir = resolve(__dirname, "node_modules/stereov/dist");
      // 直接复制到dist/vendor目录，这样才会包含在最终的构建中
      const destDir = resolve(__dirname, "dist/vendor/stereov");

      // 确保目标目录存在 (替代 fs-extra 的 ensureDir)
      if (!fs.existsSync(destDir)) {
        fs.mkdirSync(destDir, { recursive: true });
      }

      // 遍历源目录查找所有bundle.js文件
      const files = fs.readdirSync(srcDir);

      for (const file of files) {
        // 只复制bundle.js文件
        if (file.endsWith(".bundle.js")) {
          const srcFile = resolve(srcDir, file);
          const destFile = resolve(destDir, file);

          // 替代 fs-extra 的 copy
          fs.copyFileSync(srcFile, destFile);
          console.log(`✅ 已复制: ${file}`);
        }
      }

      console.log(
        "🔄 Stereov *.bundle.js 文件已复制到 dist/vendor/stereov 目录",
      );
    },
  };
}

export default defineConfig(({ mode }) => {
  // ...
  return {
    // ...
    plugins: [
      vue(),
      createSvgIconsPlugin({
        iconDirs: [path.resolve(process.cwd(), "./assets")],
        // 指定symbolId格式
        symbolId: "icon-[dir]-[name]",
      }),
      copyStereovAssetsPlugin(),
    ],
    // ...
  };
  // ...
});

stereov创建引擎时传入bundle的路径

const bundleRoot =
  import.meta.env.MODE === "development"
    ? "/node_modules/stereov/dist/"
    : "./vendor/stereov/";

if (!engine) {
  try {
    await createEngineManager({ bundleRoot }, domRef.value).then(
      (engineManager) => {
        engine = engineManager;
        engineReady.resolve(engine);
      },
    );
  } catch (error) {
    engineReady.reject(error);
    throw error;
  }
}

4. 打包模式

1. module-dev模式: 开发环境打包, 打包成module, 不压缩, 有sourcemap, 有typecheck
2. module-publish模式: 生产环境打包, 打包成module, 压缩, 无sourcemap, 无typecheck 打包结果路径在dist文件夹下
3. module-publish-debug模式: 测试环境打包, 打包成module, 压缩, 有sourcemap, 无typecheck

5. 命令

1. dev 同时执行build-dev:watch和build-view:delay 效果是打包完后持续监听并启动examples子项目
2. build-view 运行examples子项目的dev命令
3. build-view:delay 延迟6秒后执行build-view
4. build-dev:watch 执行build-dev并持续监听
5. build-dev 执行build-module-dev
6. build-module-dev 执行esbuild打包 module-dev模式
7. build-module-publish 执行esbuild打包 module-publish模式
8. build-module-publish-debug 执行esbuild打包 module-publish-debug模式, 用于生产环境下调试
9. publish 发布命令 打tag并发布到内部npm源并推送tag到远程

6. 发布

git pull 注意发包前一定要先拉代码

6.1 发布开发版本的包

yarn build-module-publish-dev 或者直接 yarn build-dev

yarn publish

版本号举例: 0.0.0-beta.101

6.2 发布生产版本的包

yarn build-module-publish

yarn publish

版本号举例: 1.0.0

6.3 发布生产版本下的调试包

yarn build-module-publish-debug

yarn publish

版本号举例: 1.0.0-debug.101

6.3 查看发布的包

时空线下私有npm网页

7. npm包的版本号

在业界，版本号的管理通常遵循语义化版本控制（Semantic Versioning，SemVer）规范。按照 SemVer 规范，版本号由三部分组成：主版本号.次版本号.修订号

7.1 版本号的变化规则：

1. 预发布版本（Pre-release Version）

   • 格式：MAJOR.MINOR.PATCH-PRERELEASE
   • 示例：0.0.0-beta.0
   • 使用场景：在正式发布前的测试阶段，或需要获取用户反馈的版本。预发布版本在正式发布前可以不断更新，版本号会变化，例如 0.0.0-beta.1、0.0.0-beta.2 等。

2. 主版本号（MAJOR）

   • 变化条件：当你做了不兼容的 API 修改。
   • 示例：1.0.0、2.0.0

3. 次版本号（MINOR）

   • 变化条件：当你在保持向后兼容的前提下添加了功能。
   • 示例：1.1.0、1.2.0

4. 修订号（PATCH）

   • 变化条件：当你做了向后兼容的问题修正。
   • 示例：1.0.1、1.0.2

5. 构建元数据（Build Metadata）（可选）

   • 格式：MAJOR.MINOR.PATCH+BUILD
   • 示例：1.0.0+20130313144700

7.2 如何调整版本号

• 从预发布到正式发布：

  • 当准备好正式发布版本时，应将预发布标签去掉，并根据修改的内容更新主版本号、次版本号或修订号。例如，如果 0.0.0-beta.0 已经经过测试并准备好正式发布，可以改为 1.0.0（如果这是主要发布）。

• 引入新功能：

  • 在已有的稳定版本上添加新功能，可以增加次版本号。例如，如果当前稳定版本是 1.0.0，添加新功能后版本号应更新为 1.1.0。

• 修复问题：

  • 在稳定版本中修复问题时，更新修订号。例如，如果当前稳定版本是 1.0.0，修复问题后版本号应更新为 1.0.1。

• 不兼容变更：

  • 如果进行了不兼容的 API 修改，主版本号应增加。例如，从 1.0.0 变更为 2.0.0。

使用语义化版本控制可以帮助清晰地传达版本的变化和改进，也方便用户了解每个版本的更新内容。