Description
Creating this issue to track interest and progress (if any) for getting Scribe.js working with CDNs, so it can be imported from JSDelivr, unpkg, etc. At present, all code must be loaded from the same domain. Thumbs up this issue if this is something that matters to you, and leave a comment if there is a significant use-case that not supporting CDNs inhibits. My current understanding is that this is a nuisance that makes it more difficult to try out the package or share a snippet, but does not stop anybody from deploying the package in production.
For context, getting Scribe.js running on a CDN is probably possible, however has already proven a headache, and the CDN version would likely need to vary significantly from the main codebase (e.g. by hard-coding a lot of URLs and/or deleting dynamic imports).
- Loading code from a CDN requires the ability to load code from a different origin.
- Browsers do not allow for directly loading workers from different origins
- Scribe.js makes extensive use of workers--nearly everything that is computationally expensive is offloaded to a worker.
- A common workaround is to create the worker from a blob, and have that blob contain code that imports the "real" worker code from the CDN.
- This is what Tesseract.js does, and despite seeming hacky, a search online indicates this is the standard method of accomplishing this.
- However, this approach breaks relative imports because the blob worker is not "relative" to any other files on the server.
- Tesseract.js solves this by building all worker code to a single file.
- This would be significantly harder in this codebase, as (1) we have many conditional imports and (2) workers can spawn additional workers.
- A less common workaround is to create the worker from a blob, and inline all of the blob code in the main file.
- This is not viable for us, as it would massively inflate the bundle due to including every optional component.