A few notes:

• This patch is not backwards compatible with previous hive versions. It'll be annoying to modify existing code for an update that doesn't add any value unless you're deploying to web. I think init method could be modified in backward compatible way like: init(String path, [HiveStorageBackendPreference? backendPreference]). Actually backendPreference parameter is platform specific but name seems like it affects the whole platform implementation, maybe we can also accept it as a static value or any other thoughts?
• Can we convert that javascript file into dart, I know it serves a purpose but afaik dart does supports most of js interface
• It would be great if we could still support previous SDK versions (eg: 2.12)
• hive_flutter should not depend on hive using path directive because when published to pub.dev it'll not be accepted.

Yes, this sounds all reasonable...

• the changes are no longer breaking (the init methods are no longer modified)
• re-wrote the web worker in Dart: before you publish versions to pub.dev or locally test Hive, you now must manually compile the web worker. As it should be uploaded to pub.dev, this is not necessary for end users.
• fixed the import

In regard of tests: I think it's not possible to run automated tests on the web worker code with the current test framework. The web worker can simply only be e2e tested with a real web browser running.

re-wrote the web worker in Dart: before you publish versions to pub.dev or locally test Hive, you now must manually compile the web worker. As it should be uploaded to pub.dev, this is not necessary for end users.

Sorry but can you explain a bit how this part should be done. Not compilation but how this script will be utilized, I don't see it's imported anywhere so what user should do to enable WebWorker support.

Sorry but can you explain a bit how this part should be done. Not compilation but how this script will be utilized [...]

Unfortunately, Dart's web worker support is not really good. It's not possible to tell the dart2js compiler to separately compile the web_worker.dart - in order to simply access it by Worker('web_worker.dart.js'). It must be manually compiled hence.

As it's a bad pattern to add compiled files to a git repository, I would propose to compile the file before uploading releases to pub.dev. Otherwise, the users would need to manually compile this file on every launch of their applications.

Before uploading to pub.dev, you manually need to execute cd hive/lib/src/backend/js/web_worker; dart compile js web_worker.dart -o web_worker.dart.js -m hence.

As far as my dart pub publish dry runs showed, pub properly understands that the .dart.js file is gitignored but should be uploaded to pub.dev anyway, as seen in the .pubignore.

I don't see it's imported anywhere so what user should do to enable WebWorker support.

It's finally imported via the Worker() constructor creating a Web Worker from the pre-compiled .dart.js file as seen in web_worker_interface.dart#23.

Would you like to review the PR?

Please note: The tests cannot succeed as your GitHub workflow does not override the dependency of hive_flutter on the local path ../hive.

I allowed myself to correspondingly adjust the tests in general in order to have local dependency overrides within the CI.

Sorry I was a bit busy those days, I'll test changes and merge in a few days. I'm very sorry for the delay. If this update is important for you (or your project) let me know (so I can re-prioritize it).

Thanks a lot. For us, it's a quite important change as we hardly struggle with the performance of Hive on the web. Together with dart-lang/language#939, we'd love to have it working soon.

As a general question, would you be willing to accept changes implementing dart-lang/language#939 (as I already started working on it)?

As a general question, would you be willing to accept changes implementing dart-lang/language#939 (as I already started working on it)?

As long as it will be backwards compatible with existing stuff, I'm fine with it. But at current stage I'm personally preferring stability over new features, and also I don't have exact numbers but I think Flutter mostly used for mobile dev rather than web (I might be wrong tho) so I would rather choose to keep mobile api stable rather than adding new breaking changes for web. But if we can find a way to add those changes without breaking compatibility (on mobile, desktop implementation) that should be fine.

I'd say if there needs to be breaking changes for the web rather be it sooner than later. I can see the web gaining popularity in a year or two when flutter and the eco system becomes more mature.

I'd say if there needs to be breaking changes for the web rather be it sooner than later. I can see the web gaining popularity in a year or two when flutter and the eco system becomes more mature.

I agree. Web is a raising platform and one of the major differences separating the Dart language as well as the Flutter framework from one or another framework out there...

I am already working on the implementation - and as of now, I see no need of breaking changes in the Hive API, even tough it causes quite many changes just within the package.

Moreover, I created an issue in the Dart language spec to have some clearer API for web worker communication: dart-lang/sdk#48813

I would like to pause this PR until the revamped FluffyBox + WebWorker PR is ready so far. Closing hence in favor of dart-lang/language#939.

Yeah I saw your feature proposal yesterday and upvoted. It's quite strange because it used to have web worker support if what I've read is correct but they dropped support. Having had to do the same kind of thing I gotta say it's quite annoying.