Conversation
|
@launchdarkly/js-sdk-common size report |
|
@launchdarkly/js-client-sdk size report |
|
@launchdarkly/js-client-sdk-common size report |
7032cb2 to
c4b16bd
Compare
| redirect: 'error', | ||
| credentials: 'omit', | ||
| cache: 'no-store', |
There was a problem hiding this comment.
would like some opinions on this one. I personally don't see a reason to deviate from current behavior (what we have in nodes http/https implementation)
| // electron.net isn't available outside a real Electron main process, so this fakes just | ||
| // enough of the ClientRequest API to drive the local test server below over Node's real | ||
| // http module. Verified against real Electron 42.6.0: Chromium's net module transparently | ||
| // decompresses a compressed body while `IncomingMessage.headers` still reports the origin's | ||
| // original `content-encoding` -- this fake reproduces exactly that (see the scrutinize | ||
| // report for the real-Electron verification), rather than handing back a raw, never | ||
| // -transcoded Node response the way a naive passthrough would. |
There was a problem hiding this comment.
This is something I had claude whip up (obviously), but it does seem like electron heavily favors e2e tests (https://www.electronjs.org/docs/latest/development/testing)... debating whether or not it is worth it to have an e2e suite that also runs to supplement test coverage.
e974fde to
86efe47
Compare
86efe47 to
a023721
Compare
This branch has not been deployed
1 participant
This PR will make it so that electron sdk will use the native
netmodule as the default HTTP transport.