React应用未加载node_modules中已更新的私有包导出项

以下按排查成本从低到高排序，逐个验证即可定位问题：

• 第一优先级清全量构建缓存，不要只重启开发服务器。绝大多数前端构建工具（Webpack/Vite/CRA/Umi等）默认对node_modules下的依赖做持久化缓存，重启服务不会主动清除这部分缓存——因为构建工具默认第三方依赖不会变更。直接删除项目根目录下的node_modules/.cache整个文件夹，再重新启动开发服务器即可，这也是这类替换node_modules文件后不生效问题的最高发原因。
• 核对npm包实际被解析的入口文件，不要以IDE跳转结果为准。IDE的模块解析逻辑和构建工具的解析逻辑并不完全一致，尤其是包的package.json中配置了exports/main/module/types等多入口字段时，IDE可能读类型声明文件、或就近匹配js文件，但构建工具会严格按照配置的入口条件加载对应文件。你可以直接打开node_modules/@getsote/react-core/package.json，顺着开发环境对应的入口字段（比如module字段对应ESM入口、exports.import对应ESM开发环境入口）的路径打开实际的入口文件，确认该文件内确实存在OrganizationsLinkIcon的导出，很多时候你替换的dist文件夹下的文件根本不是构建工具实际加载的入口文件。
• 确认构建工具加载的包路径是否正确，避免依赖提升导致的多版本包问题。如果是monorepo项目、或使用pnpm/yarn做依赖管理，很可能存在多份@getsote/react-core被安装在不同的node_modules层级，你修改的是当前项目下的包，但构建工具因为依赖提升规则，实际加载的是被hoist到上层目录、或其他子包下的旧版本包。可以在项目的业务代码入口处加一句console.log(require.resolve('@getsote/react-core'))，启动服务后看控制台打印的绝对路径，顺着路径找到实际被加载的包文件，确认是否是你替换过的版本。
• 验证模块格式兼容问题。如果前面的排查都确认文件加载正确，检查你替换的dist文件的模块格式是否和入口配置匹配：比如入口配置指向的是CJS格式文件，但你只写了ESM的export {}语法，没有对应CJS导出，Webpack在解析CJS模块时会扫描module.exports上的挂载属性，会识别不到你新增的导出。可以在你认为会被加载的入口文件最顶部加一句console.log('debug: 我修改的react-core包被加载了')，重启服务如果控制台没打出这句话，说明你改的文件根本没被加载，回到前面的路径、缓存环节排查。
• 快速验证方案：如果以上排查都没定位问题，可以先在业务代码里用相对路径直接引用你本地开发的包的dist文件，比如import { OrganizationsLinkIcon } from '你的本地包绝对/相对路径/dist'，如果这样引用能正常加载，说明你的包代码本身没有问题，故障100%出在模块解析、缓存环节。

pnpm用户可以额外尝试执行pnpm dev --force强制跳过依赖预构建缓存，部分场景下软链接的异常也会导致修改的文件不生效。

内容的提问来源于stack exchange，提问作者lulliezy