mfe-route 规范

目前 mfe-route 只支持 json 作为其扩展名称, 未来不排除支持其他类型的 mfe-route.

mfe-route 拥有三个字段:

{
    "domain":[],
    "index":"",
    "rewrites":[]
}

domain (SPA)

domain 字段是可选的, 主要用于 SPA 项目中.

它描述了这个项目所涵盖的路由规则:

{
  "domain":[
    "/",
    "/home",
    "/about/*",
    "/about/:username/:id"
  ]
}

当路由与数组中的规则进行匹配成功后, 则分发持有这个 mfe-route 路由所对应的项目的静态资源.

路由匹配规则的规范取决于你是否使用 mfe-proxy-middleware 和 mfe-proxy-server, 如果两个都使用则需要是匹配规则兼容两者.

mfe-proxy-server 基于 fastify 使用 find-my-way 作为匹配工具

mfe-proxy-middleware 基于 express 使用 path-to-regexp 作为匹配工具

fastify 文档地址

express 文档地址

该属性源自 connect-history-api-fallback 如果你熟悉的话两者是一致的.

这个字段决定了 SPA 项目默认的 HTML 文件相对于打包目录的位置, 默认是输出目录下的 index.html.

{
  "index":"index.html"
}

所有与 domain 匹配的路由都将返回这个文件,

该属性源自 connect-history-api-fallback 如果你熟悉的话两者类似. 实现上不支持 connect-history-api-fallback 所使用的正则表达式, 而是专用的匹配规则.

考虑到兼容问题你能使用的路由匹配规则是 find-my-way 与 path-to-regexp 的交集:

/*
/about/*
/user/home/:id/*
/foo/bar

不过幸运的是这两个类库的匹配规则在很大程度上都是一致的, 如果要使用高级用法记得去查看各自的文档.

{
  "rewrites": [ { "from":["/foo","/bar","/*"], "to":"index.html" } ]
}

和 connect-history-api-fallback 不同的一点是 from 属性除了使用默认的字符串外还可以使用数组.

同时使用 domain 和 rewrites 的时候,出于 rewrites 上的路由更加具体的考虑. rewrites 会优先匹配.

如果你在 rewrites 上配置了针对 index.html 的规则, 很可能 domain 中的规则将没有效果, 建议只配置 rewrites.

另外由于 mfe-proxy-server 不支持重复的路由地址, 所以在实际交由路由前所有的地址都会被去重, 去重后靠前的路由优先级比靠后的高.

当存在多个项目的时候, 每个项目都拥有自己的路由规则, 这些规则很可能是重复的, 或者一个请求可以同时匹配项目 A 和项目 B 的规则.

对于 mfe-proxy-middleware 路由规则注册的顺序就是在 mfe-config 中所定义的项目顺序, 由于基于 express 所以路由规则也是按照顺序匹配的先匹配到的先执行.

对于 mfe-proxy-server 路由规则注册的顺序是基于 mainfest.json 文件决定的, 由于 fastify 不支持重复路由注册, 在使用前会安装顺序将后定义的重复路由排除.

fastify 会在内部建立一颗用于索引的树, 如果出现了两个规则同时匹配同一个 url 则更加具体的规则会优先匹配.

所以项目的先后顺序非常重要, 因为会存在去重的问题. 其次不建议在不同项目间出现可以同时匹配同一个 url 的路由规则, 但可以完全一致因为可以被先后顺序规则覆盖.

如果出现了这种问题匹配同一个 url 的规则则需要将 /test/* 这种通配规则改为 /test/foo, /test/bar 这种更加具体的规则.

mfe-proxy-middleware 将会忽略这个项目.
mfe-proxy-server 将会根据配置托管项目, 由于没有了 mfe-route 所以不会匹配任何规则, 只用于纯静态文件的分发.