从Yarn 1升级到Yarn 4后执行yarn build报错permission denied: .

嘿，我之前也碰到过一模一样的问题！Yarn 4（也就是Yarn Berry）和Yarn 1的脚本执行机制差得挺多，这就是你报错的核心原因。

问题根源 #

Yarn 1会直接在当前终端的shell环境里跑你的脚本，而Yarn 4默认用了更隔离的执行环境，对脚本调用方式和权限的管控更严格。你原来写的. ./build.sh是用source命令加载脚本，这种写法在Yarn 4的默认执行上下文里会触发权限问题，它没法正确处理当前目录的source操作。

解决方案 #

这里有几个靠谱的解决办法，你可以按顺序试试：

1. 直接执行脚本而非source
   如果你的build.sh不需要在当前shell环境中保留变量（只是单纯执行构建命令），可以改成直接调用脚本的方式，同时确保脚本有可执行权限：

   • 先给build.sh加可执行权限（本地和CI环境都要做，CI可以把这步加到构建流程里）：

     chmod +x ./build.sh
     

   • 修改package.json里的build脚本：

     "scripts": {
       "build": "./build.sh"
     }
     

   要是怕CI环境每次都要手动加权限，也可以把权限命令整合到脚本里：

   "scripts": {
     "build": "chmod +x ./build.sh && ./build.sh"
   }
   

2. 明确指定shell执行source命令
   如果你必须用source（比如脚本里设置了后续流程需要的环境变量），可以指定用bash来执行整个命令，绕开Yarn 4默认shell的限制：

   "scripts": {
     "build": "bash -c '. ./build.sh'"
   }
   

3. 检查Yarn 4的工作目录配置
   极少数情况下，Yarn 4的nodeLinker配置（比如设为pnpm）可能会改变工作目录的权限，你可以在项目根目录的.yarnrc.yml里检查这个配置，要是不需要特殊的链接器，可以改成：

   nodeLinker: node-modules
   

   改完后记得运行yarn install重新生成依赖。

额外提示 #

在CI环境里，还要确保构建用户有足够的权限访问项目目录，有些CI容器的默认用户权限比较严格，必要时可以在CI步骤里调整，但优先用前面的脚本修改方案，尽量避免用sudo。

内容来源于stack exchange