[web_assets] Scaffold package - #3610

Can you explain more about what worker files are and how they are different from things you directly call via js interop?

Workers are basically the Isolate.spawnUri of the web. They take a URI parameter and make the browser start executing the script at that URI in a new thread. Communicating with workers is also similar to how things work with isolates, one uses postMessage to send objects to workers and a message event handler to receive objects from a worker. Dart code using workers would create workers and invoke these functions via dart:js_interop.

The main difference to interop with JS libraries is that workers can't be bundled directly into the main Dart program (there's is no equivalent of Isolate.run taking a JS function to run as a worker). If we had a "this is a JavaScript library I want to invoke from Dart" asset type, it wouldn't be unreasonable to expect embedders to merge compiled Dart programs and that library into a single JavaScript file (the JS ecosystem has many tools doing exactly that). This wouldn't work for workers, which need to be represented by a URL at runtime.

(of course, one can also represent JavaScript libraries by their URL at runtime and then import them, but I'd say that's a stopgap solution until we have proper JS library asset types)

I don't think it makes sense to have an asset type specifically for workers as there are other web APIs identifying resources via URLs, and those would work in exactly the same way. URL assets are the most generic asset type for the web: Embedders are not allowed to alter their contents in any way.

I agree with your suggestion of adding additional asset types that can be transformed (WASM, WASMGC, JS). I can rename the current URL asset to web_assets/url (or web_assets/generic? 🤔) to make it clear that we'll have additional asset types in the future.

images/sounds/icons/fonts -> I think these should be data assets and when Dart/Flutter encounter those with a web backend it should copy them to the right place.

An AssetBundle in Flutter (which I understand is where data assets currently end up in) doesn't expose URLs, so the assumption with data assets is that you'll only need to load them as a Future<Uint8List> at runtime (which is important, it means embedders could store data assets in an archive, embed them in the executable or a data section in WASM instead of preserving separate files). If we had a way to resolve data assets to URIs (which would restrict embedders!), the asset type added in this PR wouldn't be necessary.

(there's is no equivalent of Isolate.run taking a JS function to run as a worker)

Is that something we should consider solving? Because if we solve it, you can run Dart code as a web worker, and if that Dart code happens to use js-interop and a js asset it's the same as all other JS interop.

URL assets are the most generic asset type for the web: Embedders are not allowed to alter their contents in any way.

To me that kind of sounds like data assets. If the contents are not altered in any way, no minifying, etc. However, Data assets can only be accessed by bytes right now, they are not guaranteed to have a file path on native or an url on web. And embedders might inline the bytes into the app if they see fit.

So, if we then need a kind-of-data-asset-but-it-must-have-a-url on the web, then web_assets/web are those. And we would introduces web_assets/wasm and web_assets/js later. Maybe web_assets/data_url or web_assets/url would be better? And then UrlAsset(...) which is an asset that is at runtime accessible via an url.

Oh, I am basically retyping what you said without reading your full message 😄 that means we are on the same page! 👍

Then adding UrlAsset in this PR SGTM!

(Url assets basically give you the capability lazy load things on the web. Ditto we could have a data_assets/file FileAsset for which embedders must provide a file path instead of just the bytes. I'm not yet entirely sure if I want all of those capabilities/contracts as different asset types or as properties on one asset type. But maybe different asset types is cleaner. The only result is that if it's different asset types you end up branching in your hooks with: if it's web report a UrlAsset() and if it's native report a DataAsset() -> but if you actually also use different code at runtime, that is not that ugly. E.g. on web you load from a url, and on native you load the bytes. This line of thought is to be continued and explored later. For now I think url assets make sense.)

CI seems red. @simolus3

note to self:

• need to publish the first version of the package manually and transfer it to labs.dart.dev
• then set up auto-publishing

@dcharkes I have fixed the test failures, could you take another look?

Codecov Report

❌ Patch coverage is 88.48921% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.97%. Comparing base (57b4bad) to head (e56bcbe).

@@           Coverage Diff            @@
##             main    #3610    +/-   ##
========================================
  Coverage   87.96%   87.97%            
========================================
  Files         307      311     +4     
  Lines       19662    19801   +139     
========================================
+ Hits        17296    17419   +123     
- Misses       2366     2382    +16     

simolus3 and others added 3 commits 12 hours ago

@simolus3 did you use multiple email addresses? If yes they all need to sign the cla. 😅 Or just squash and reupload with 1 email address.

Also, we've switched to codecov from coveralls, and apparently the default is now that you have to have a certain percentage covered. (It's easy to task an agent to write some extra tests. See my last 10 PRs on this repo 😆)

I've added a few more tests which should cover most of these files now.