Daniel Bate

@Torres-ssf any thoughts on this as I know you've worked alot with the docs and snippets

Current work in progress report on browser compatibility testing: So far I’ve tried a number of different approaches and tackled a few different challenges that can be summarised into the...

Pausing the Vitest investigations for now. Currently impressions are that it is very fast (will benchmark once the full suite runs) and requires minimal configuration compared to Jest, but there...

After upgrading a few packages to better integrate with Vitest, still experiencing some issues. - [Blocked headless mode](https://github.com/vitest-dev/vitest/issues/3930) - Polyfilling causes browser tests to run very slowly - Browser tests...

Completion checklist: - [x] Infrastructure and CI - #1630 - [x] Crypto package - #1630 - [ ] Other packages > There is currently an issue with polyfilling `fs` blocking...

I had assumed that we would want to test most of them on browser given that is our integration suite. However, if we only want a few specifically for browsers,...

Sorry yes I was referring more towards domains. But correct, right now most of fuel-gauge uses `fs` and I'm running into an issue with the polyfill, but I would like...

Apologies, I am not explaining myself well. Regarding domains I was referring to domains within our SDK, so whether we want to browser test `crypto` or `address` etc. specifically. Regarding...

An external package may not even be needed here. We could implement something based off the native `Date` object, wrap our own functionality such as `fromTai64ToUnix` and document how it...

@FuelLabs/frontend may be able to weigh in here as to what the better internal store format should be? I'd probably recommend UNIX due to it's flexibility unless said otherwise.