【RFC】让 Pake 支持注入外部 js 文件

[jeasonnow]

Why

目前观察到 Tauri 作为基于系统 webview 的跨平台应用开发框架，其相较于使用成熟的 chromium，会有很大的体积优势，但是相对的会存在系统 webview 没有实现一些需要外部进程或者系统 native 去做的相关能力：摄像头、话筒的调用，系统默认的 alert | prompt 等。(感觉上系统的 webivew 应该只负责实现浏览器中从 url 到页面渲染的通路，而涉及和 native 的部分其实不做实现只是遵循规范提供 api 占位)

对于直接使用 Tauri 的开发者来说还好，因为可以通过自行完善 一些 native 功能来规避这些问题，但是如果通过 pake 打包的 web 应用中使用了这些能力，则会导致应用打包出来有巨大缺陷，比如之前一些 issue 和 discussion 里提到的：
#421
#422

How

针对上面提到的问题，我想到两种方案去解决：

• 短期的：等待官方或者自行实现 rust 端原生的功能，通过在注入的 js 中对 prompt 等无法调用的 api 进行拦截，并通过 invoke 去调用原生的方法解决。
• 长期的：我们可以尝试让外部自行定义一些补丁文件，在 build 前将外部的补丁文件直接通过 build 环节正式触发 tarui 的构建前生成一个本地文件并放置到指定目录，通过 rust 注入到 window 中，实现外部自行为页面进行补丁的功能。

它大概是这样去使用：

$ pake https://example.com --name Example --transparent --scripts ./patch.js,./patch2.js --debug

What

根据配置合成脚本放到指定文件目录

export default async function combineExternalScripts(scripts: string) {
  const files = scripts.split(',').map(relativePath => path.join(process.cwd(), relativePath));
  const output = path.join(npmDirectory, 'src-tauri/src/inject/dynamic.js');

  const contents = files.map(file => fs.readFileSync(file, 'utf-8'));
  fs.writeFileSync(output, contents.join('\n'));
}

注入到 pake 页面中进行执行

let current_dir = env::current_dir().unwrap();
let dynamic_path = PathBuf::from("src/inject/dynamic.js");
let absolute_path = current_dir.join(dynamic_path);
match fs::metadata(&absolute_path) {
    Ok(metadata) => {
        if metadata.is_file() {
            window_builder = window_builder.initialization_script(include_str!("../inject/dynamic.js"));
        }
    }
    Err(_) => {}
}

通过这样的流程，可以实现在 pake 中达到类似使用油猴脚本的效果。当然如果出于某些作用域限制，也可以在合并外部 js 时手动控制一下暴露给外部 js 的 api 和上下文信息。

More

这样的思路或许可以适用于后续插件系统的构成，但是需要统一外部 js 具体的组织形式或者数据结构，重新调整合并和注入到页面逻辑。

[jeasonnow]

代码示例：6299677

[tw93]

此外这里我觉得甚至可以我们内置不少通用的能力进去，这样一方面可以让使用者更简单，一方面可以让Pake本身功能更全面
对于有定制的，但是不通用的，我们就推荐用户用这种方式

[jeasonnow]

这个思路挺好的，也即自定义注入，甚至对于样式的定制修改上面，我之前比较喜欢这个 electron 打包工具的用法，你看看
https://github.com/nativefier/nativefier/blob/master/API.md#inject

这个很 ok ，就是我想实现的方式。我想应该可以把之前注入的 js 内容从原有的 src-tauri 中抽出来作为内置注入内容，和外部的进行合并一起注入到 pake window。

[tw93]

没问题 我认为可以弄，不过这里应该只是用于解决 命令行一键打包的注入问题，场景也比较清晰

后续这个能力我认为可以放出来，比如说应用首次打开的时候，在用户对应这个应用的配置文件夹里面放一个新文件夹 inject，里面默认就是一个css、一个js，可以让有能力的同学去自定义，然后入口通过放到菜单栏上面的某一个入口给打开

不过这里还有一个注意点就是，只针对开了debug模式的用户，默认不开，但是个人爱好者使用可以自己打开就好

[jeasonnow]

我感觉这种注入可以给 Pake 带来更多玩法：比如我喜欢使用一些限制很多/交互很烂的网页应用，而恰好有些脚本可以帮我解除这些限制，在之前的浏览器场景里，我需要学习脚本的安装/设置/使用，才能在浏览器里体验最优的效果。而如果我们可以支持在构建应用程序环节直接注入，那么用户收获的将是一个开箱就是最佳体验效果的应用，而无需任何的学习过程。

这甚至可以诞生一个新的 discussion：分享你自己生成最好用的某个 app

所以要不要直接对非 debug 模式也放开限制试试？

[tw93]

哦哦 原来你说的这个，我认为没有问题的，我当时是想着没有devtools模式用户自己用可能不好调试，不过其实还好，在自己浏览器调试其实也一样