本地虚拟化共享模块,而非云端共享模块,类似本地调试的感觉

[itmanyong]

想法来自于hel的本地调试，可以自定义preFetchLib的获取源host。有很多时候需要使用的包全部都是本地化的部署，例如:某一内网，不涉及公网环境。虽然目前可以指定源。但如果preFetchLib的包未发布(即包不能通过npm的形式安装到项目中)，虽然目前也是支持获取内网共享模块的，但使用上不太统一不是很优雅。 公网可安装的npm包使用方式为:

import helJsLib from 'hel-jsLib';
await preFetchLib('hel-jsLib')
// 然后就可以使用helJsLib中共享模块了
helJsLib.xx.xx

公网未安装的依赖共享包当前可使用方式:

// 先加载
const lib = await preFetchLib('虚假的包名',{custom:{host:'http://xxx.xxx'}})
// lib可以正常使用
lib.xx.xx
// 如果多个地方需要使用,要么挂载到windiw或者项目内的某一变量也是可以达到效果的
// 挂载到某一变量
globalVar.jsLib = lib;

// 其他文件使用时先获取到globalVar再调用可行
globalVar.jsLib.xx.xx

1.未发布的内网共享模块与已发布的模块使用差别上有所区别，个人觉得不是很优雅，有点黑魔法的味道 2.如果后面使用的共享模块已安装且可访问公网，从内网使用模块方式切到公网模块使用方式上需要改动的地方较多 3.如果将'虚假的包名'通过类似于 libReady 的api生成一个假的包，达到和libReady提供的能力一样的效果,这样未发布的内网共享模块也可以和公网环境的共享包达到一致的使用体验。 如下的使用:

// 假如 hel-mirco 提供一个 libLocalReady 的api,使用者角度的伪代码如下
const localLibName = `本地自定义的名称`;
// 配置生成本地虚拟的包
await libLocalReady(localLibName,{custom:{host:"http://localhost:9999"}})

// file to other.ts 
// 和公网已发布的包一样先导入直接使用
import localLibName from 'localLibName'
localLibName.xx.xx

[fantasticsoul]

custom 用于本地联调之用，不建议作为是未部署版本切换到已部署版本的后门 😭

[itmanyong]

custom 用于本地联调之用，不建议作为是未部署版本切换到已部署版本的后门 😭

是有点后门的意思！实际想要表达的是内网共享模块的使用是否可以和公网模块一样。这样就全部本地化了。也能覆盖不通外网的场景

[fantasticsoul]

见这个示例： https://codesandbox.io/s/demo-load-remote-vue-comp-st0295 包体可以部署咋任何地方，重写getSubAppAndItsVersionFn即可

[fantasticsoul]

支持自定义请求模块元数据的链接，关闭此issue。