microsoft / onnxruntime

ONNX Runtime: cross-platform, high performance ML inferencing and training accelerator
https://onnxruntime.ai
MIT License
14.79k stars 2.94k forks source link

[Web] Feature Request: workaround for bundlers when using onnxruntime-web #22615

Open fs-eire opened 4 weeks ago

fs-eire commented 4 weeks ago

Summary

This issue is created to track the status of onnxruntime-web's workaround for bundlers.

What is workaround for bundlers and why?

workaround for bundlers means extra codes that required to make onnxruntime-web as a library consumable by a web app or other libraries, while those extra codes are supposed to be unnecessary but exists because of various reasons.

What are the known issues:

  1. import.meta.url as a runtime JavaScript expression, is usually rewritten into a static string starts with "file://" by WebPack as a default behavior. A few other bundlers followed this behvior. This means it is very difficult to use ESM dynamic import in the implementation.

  2. Vite development mode does not support "real" ESM. It uses some complicated steps to transcript the ESM sources into IIFE/cjs. https://github.com/microsoft/onnxruntime/pull/22196 tries to fix this but the fix is incompatible with Vite release mode.

  3. Some framework (eg. SvelteKit) always load onnxruntime-web in a Node.js context even if SSR is disabled . https://github.com/microsoft/onnxruntime/issues/22361#issuecomment-2439411518

  4. Emscripten is not able to generate both ESM/commonJS glue file in a build. (https://github.com/emscripten-core/emscripten/issues/21899)

Why is it difficult to fix:

It's all about dynamic loading with bundler involved.

onnxruntime-web has 4 dynamic loading target:

Considering the following requirements:

It's not hard to conclude that:

For example:

There are more case that makes onnxruntime-web not working out-of-box in different combinations of dev frameworks, bundlers, dev/prod modes and so on, and one fix for a specific usage may even break a specific existing working usage.

It seems that there is no way to make every use scenario work. Need to track issues and find workaround for each.

ollema commented 4 weeks ago

there are workarounds for issue 3 - but they involve patching this package to remove the "node": null entries so I am not sure if that can be called a workaround: https://github.com/ollema/g-split/commit/15f616cb8c10b3a32243ca4c872c1bce0ff44f8e