Craig Macomber (Microsoft)
Craig Macomber (Microsoft)
I don't think this is really fully a testing issue, but an error reporting issue. I've had non-test users have similar issues where they spend a lot of effort debugging...
Issues which I think need to be addressed related to this: 1. The above mentioned limits are for AFR. The two repros I'm aware of for this were with different...
> (I recently had some issues with esm.sh importing multiple (non-singleton) instances of these modules) I think that's actually an unrelated (and pretty common) issue. Requiring that all users use...
Still useful.
> I think the testing story really needs to be addressed before we expand usage here. Real bugs can happen when test code and prod code diverge, which this seems...
> To be honest I'm not totally clear on how it all works, but maybe individual packages could test both somehow? I think in most our package.json's we have targets...
Still useful.
> Follow-up idea: maybe we could use a policy handler that ensures (or tries its best to ensure) that `test:mocha` invokes `test:mocha:prod` if a package uses `debugAssert` anywhere, so it's...
> > This PR includes examples of three approaches for catching such issues: > > > Cases where debugAssert is more heavily used can have test suites which explicitly disable...
Looks like jest's "jest-environment-jsdom" library pulls in an old jsdom (version 20) which lacks the support for crypto.randomUUID which was added in 22.1. I have added an override to mitigate...