关于umijs开发环境的绝对路径问题

[arcelan]

背景：
目前团队在cloudide开发环境中使用umi时，碰到一些路径配置的问题，
cloudide启动开发模式时，并不是通过localhost访问，实际页面的访问路径类似于 https://ide.org/auth/ide-xxx/proxy/8000/
然后碰到以下两个疑问

问题1: 【publicPath和base配置】的路径问题

首先开发模式不允许publicPath设置为'./', 这个umi团队应该有自己的考虑才加了这个限制，但这个限制确实使用起来不太方便，
这里我就得设置为 publicPath: '/ide-xxx/proxy/8000/'，不是很优雅。
另外一个问题就是，如果设置了publicPath，那么base就必需设置成和publicPath一致，否则项目启动失败，因为/ide-xxx/proxy/8000/umi.js会加载失败，这一点umi配置文档也没有提及。
本来我的理解是base设置只跟路由相关，跟静态资源应该是无关的，现在看这个理解应该是错误的，望解答一下。

问题2: 【__umi/api/bundle-status】的绝对路径问题

在项目启动时，会有一个中间页面显示打包进度，
这个页面会请求一个API __umi/api/bundle-status,
对应代码在packages/preset-umi/assets/bundle-status.html

   function loadData() {
        fetch('/__umi/api/bundle-status')
          .then((res) => res.json())
          .then(check);
      }

这里是写死的绝对路径，这样就导致这个bundle-status接口失败，因为实际这个接口地址为 /auth/ide-qz00vyx5/proxy/8000/__umi/api/bundle-status

请问这个有无好的解决方法，或者说是否可以跳过这一步骤

[fz6m]

现在市面上的 IDE 基本上都是给一个子域名的方式提供 preview 预览页面，比如 vercel ，codesandbox 等都是给一个 ${hash}.preview.domain.com 类似的子域名来提供预览，因为有太多工具和框架（包括 umi）其实是默认你就在根路径上开发的，如果你用 vue-cli 这种上个时代使用量最大的 vue 脚手架，他也是需要同时配置 publicPath 和 base 才能在子路径上展示，所以预览是 https://domain.com/subpath/xxx/ 这种在子路径上 preview 其实是和社区共识不相容的，也破坏了很多社区默认的做法，所以你的第一个问题，其实对你造成的成本就是要多加 publicPath 和 base 的配置，这个配置可以通过自己写一个 umi 插件去解决，比如你可以让 IDE 环境自动注入一个 process.env.XXX_IDE_DOMAIN_PATH ，然后你在 umi 插件里，判断下如果是 cloud ide 环境且为开发时，就把它设置给 publicPath 和 base 就行，这样就可以自动化这个流程，或者你在提供 umi 的启动模板时，就把这个环境变量写到配置文件里，这样用户就不需要自己每次去改这个 sub path 了。

第二个问题如上文中所述，cloud ide 的预览 url 需要改造设计，换言之，这个 cloud ide 如果你们要以产品去卖的话，用户侧用了其他的各种各样的工具也会出现非预期的 path 问题，因为共识就是默认在根 path / 下，所以未来去改造这个 url 结构变成子域名是在所难免。

[arcelan]

感谢回答！

确实泛域名应该是最好的解决方案，不过想确认一下有没有临时的解决方法。

对于问题1，vue-cli其实是支持publicPath配置为相对路径的'./'，不过这个问题也不大，只要配置一下就好了。

对于问题2，也不是阻塞性问题，只要等bundle结束再访问页面就行了。

不过现在碰到一个阻塞性的问题3，就是base配置之后，umi会有一个重定向的逻辑，

对应代码应该是 packages/preset-umi/src/commands/preview.ts

if (
    historyType === 'browser' &&
    api.config.base !== '/' &&
    (_req.path === '/' || _req.path === '/index.html')
  ) {
    return res.redirect(api.config.base);
  }

  next();
});

在本地开发的时候这个重定向没有什么问题，但是在cloudide里面，出现了奇怪的重定向，见下图，

config中 base 和 publicPath 配置如下

base: '/auth/ide-qz00vyx5/proxy/8000/',
publicPath: '/auth/ide-qz00vyx5/proxy/8000/',

请问这种还有办法抢救一下吗？还是只能魔改umi源码了？

[fz6m]

我试了一下本地配置你的这个 publicPath 和 base 访问是没问题的，当访问 / 时会重定向到 base 去。

但我理解你在云 cloudide 里直接访问的就是 http://domain.com/auth/ide-qz00vyx5/proxy/8000/ 吧，为什么会存在跳转的情况呢，如果你访问 http://domain.com/ 就是访问了一个和 preview 环境不一样的地址，应该啥也找不到，此时提供的路由可访问范围应该仅在 http://domain.com/auth/ide-qz00vyx5/proxy/8000/* ，除此之外的路径都应该访问不到这个项目，所以如果出现了非预期的情况，就得排查下 cloudide 的代理转发策略或者 nginx 的反向代理等配置问题了（配置或者代理错了，或者自己偷改了 location 等）。

[arcelan]

是的，本地完全没有问题。

cloudide环境，浏览器直接访问的就是 http://domain.com/auth/ide-qz00vyx5/proxy/8000/，
奇怪的是，如果不设置 publicPath 和 base 是不会出现这个302重定向，至于这个location为什么会这样确实没搞清楚，我可以再debug试一下。

不过cloudide里面其他vue-cli的项目，把publicPath设置为'./'，访问也是正常的。

[arcelan]

最新的搏斗结果分享

尝试1，尝试将publicPath设置为'./'
将packages/preset-umi/src/features/check/check.ts当中的onCheckConfig注释掉，程序可以起来了，
但是./umi.js加载404了，失败。

尝试2，将base设置为'./'
这个更失败了，由于以下代码，导致页面无限302了，另外之前重定向的代码应该是找错了，今天debug了一下，发现是下面的代码重定向的，packages/server/src/server.ts

export function createRequestHandler(opts: IOpts): RequestHandler {
  return async (req, res, next) => {
    if (
      opts.historyType === 'browser' &&
      opts.base !== '/' &&
      req.path === '/' &&
      process.env.DEV_SERVER_REDIRECT !== 'none'
    ) {
      // 如果是 browser，并且配置了非 / base，访问 / 时 redirect 到 base 路径
      res.redirect(opts.base);
    } else if (
      req.headers.accept?.includes('text/html') ||
      req.headers.accept === '*/*' ||
      req.path === opts.base
    ) {
      // 匹配路由，不匹配走 next()
      // const routes = createServerRoutes({
      //   routesById: opts.routes,
      // });
      // const matches = matchRoutes(routes, req.path, opts.base);

      // 其他接受 HTML 的请求都兜底返回 HTML
      res.set('Content-Type', 'text/html');
      const markup = await getMarkup({ ...opts, path: req.path });
      res.end(markup);
    } else {
      next();
    }
  };
}

另外再补充一点调查细节，目前cloudide里面的URL转发策略也有问题，用户访问实际是/auth/ide-qz00vyx5/proxy/8000/，但是umi底层express框架req.path接到的是'/'

[arcelan]

又一次尝试，发生了更神奇的事情。

将base设置为'/'，将publicPath设置为空字符串''，这个在本地可以正常运行，以为解决了问题。
结果在cloudide环境这样配置，生成的html模板出现了问题，如下:

// 本地生成的script，没有问题，可以正常加载
<script src="umi.js"></script>

// cloudide生产的script， 这是什么 src属性怎么没了？？？
<script>umi.js</script>

我想调试一下，结果本地看到代码运行了 packages/server/src/server.ts 的 getMarkup 方法，
而cloudide环境这个方法居然没有执行

[fz6m]

问题出在：

目前cloudide里面的URL转发策略也有问题，用户访问实际是/auth/ide-qz00vyx5/proxy/8000/，但是umi底层express框架req.path接到的是'/'

这是 cloudide 转发策略或者网关、nginx 等中间层在处理的时候把 /auth/ide-qz00vyx5/proxy/8000/ 的请求给转发到项目容器的 / 去了，这是不对的，hack 源码的话会影响到其他逻辑，不能 patch umi 源码，应该解决下这个转发策略。要不就尝试下 publicPath 配 /auth/ide-qz00vyx5/proxy/8000/ ，base 不配看看。

[arcelan]

要不就尝试下 publicPath 配 /auth/ide-qz00vyx5/proxy/8000/ ，base 不配看看。

这样尝试也不行，这样配置之后，由于path转发的问题，实际umi.js的真实访问路径是 /auth/ide-qz00vyx5/proxy/8000//auth/ide-qz00vyx5/proxy/8000/umi.js，又一次导致加载失败，看来只能解决网关path转发的问题。

最后好奇请教一下，umi为啥不允许开发环境设置 publicPath为 './' ？

[fz6m]

据我所知由于 umi 4 已经从 2021 开始开发到现在 2 年多，历史设计里就没考虑从相对路径加载，所以开发时服务全是默认从 /xxx 开始加载的，后面功能多了就很难改了，另外目测蚂蚁内也没有要从 ./ 开发的需求，所以他们不需要这个吧。