There is one piece of the puzzle still missing - the files are being
sent wholesale instead of being streamed - and this might cause memory
issues. I haven't benchmarked yet, leaving this until we get some
response from the upstream issue
https://github.com/electron/electron/issues/41872 (hopefully it's just
some thing I missed).
But otherwise, ran export on a trivial library and it worked fine, so
everything is at least hooked up properly now.
local.yaml is only loaded in the local environment, and will not be used
in production. To avoid specifying it in both production and local
configurations, use it as a default specified in the code instead
(that's the pattern we're using in other places too from what I
remember, maybe we should refactor that too, but that's a bigger task
not tied to this change).
**Tested by**
On a local dev cluster
- [x] Not specifying anything and ensuring that the default is picked
- [x] Specifying an override in museum.yaml and verifying that is used
instead
local.yaml is only loaded in the local environment, and will not be used in
production. To avoid specifying it in both production and local configurations,
use it as a default specified in the code instead (that's the pattern we're
using in other places too from what I remember, maybe we should refactor that
too, but that's a bigger task not tied to this change).
**Tested by**
On a local dev cluster
- Not specifying anything and ensuring that the default is picked
- Specifying an override in museum.yaml and verifying that is used instead
This was primarily for getting the latest Electron, but I ran `yarn
upgrade-interactive` and upgraded the other non-breaking deps (mostly dev) too.
Reason for wanting electron is to try and see if this backport fixes the issue
with our streams not getting faithfully written:
https://github.com/electron/electron/pull/41052
In some ad-hoc and quick testing, I noticed that the new `writeStream` we've
implemented works fine for files up to 128 K, presumably some chunk size, but
then begins to diverge. Sounds similar (but not exactly the same) as this issue:
https://github.com/electron/electron/issues/39658
Unfortunately, this didn't fix the issue we're facing, so our case is perhaps
different.
## Description
Ran into error after clearing search bar of queries by hitting
backspace.
> The error is shown below
> Thank you to the team for considering
## Tests
**Error**
**Fix**
Fixed by wrapping the line-causing error around by an `if` block.
Attempt to solve the following error in the browser's console when trying to
make the request:
[error] download and save failed: TypeError: Failed to construct 'Request':
The `duplex` member must be specified for a request with a streaming body
Supressing it for now since it obscures other important information in the console.
Upstream issue, which currently doesn't have a workaround:
https://github.com/catdad-experiments/libheif-js/issues/23
Full error message:
⚠ ../../node_modules/libheif-js/libheif-wasm/libheif-bundle.js
Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
Import trace for requested module:
../../node_modules/libheif-js/libheif-wasm/libheif-bundle.js
../../node_modules/libheif-js/wasm-bundle.js
../../node_modules/heic-decode/index.js
../../node_modules/heic-convert/index.js
./src/worker/convert.worker.ts
./src/utils/comlink/ComlinkConvertWorker.ts
./src/services/heic-convert/service.ts
...
Refs:
- https://stackoverflow.com/questions/38392697/webpack-umd-critical-dependency-cannot-be-statically-extracted
