<!-- Thanks for contributing! -->

Purpose

Changes

Additional information

<!-- Mark the ones you have done and remove unnecessary ones. Add new tasks that fit (like TODOs). -->

• [ ] I updated readme
• [ ] I added unit test(s)

<!-- Add - fix #_NUMBER_ line for every PR/Issue this PR solves. Do not comma separate them. -->

• fix #000

• There is just but a tiny thing i discovered about disc based blob not being transferable across workers a few days ago.

• And then i think there is the kuku problem about the meta key/value type all being casted to all lowercase ( https://github.com/w3c/FileAPI/issues/43 )<br>It currently doesn't use "parse a MIME type", but it should.

but i don't think this 2 should be such a huge blocker. for adding it to the global scope

@Aschen NodeJS v19.8 just got released with support for fs.openAsBlob(path, { type }) and fyi: i have already develop a more spec compatible blob impl way back: fetch-blob

I notice that blobs transfered over workers aren't readable at all.

• it only applies to blobs coming from fs.openAsBlob
• in-memory constructed blobs works fine.

mini repro:

import { Worker } from 'worker_threads'
new Worker('./worker.js').once('message', blob => blob.text())

// worker.js
import { parentPort } from 'node:worker_threads'
import { openAsBlob } from 'node:fs'

const blob = await openAsBlob(import.meta.url.slice(7)) // file:// doesn't work
parentPort.postMessage(blob)

I would assume that if you also closed the worker it would still work just fine to read the blob, even if it came from another thread...

<details> <summary>Error stacktrace</summary>

FATAL ERROR: v8::HandleScope::CreateHandle() Cannot create a handle without a HandleScope
 1: 0x104e1df7c node::Abort() [/opt/homebrew/Cellar/node/19.8.1/bin/node]
 2: 0x104e1f33c node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
 3: 0x104f7a064 v8::Utils::ReportApiFailure(char const*, char const*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
 4: 0x1050cb130 v8::internal::HandleScope::Extend(v8::internal::Isolate*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
 5: 0x104f7bf04 v8::EscapableHandleScope::EscapableHandleScope(v8::Isolate*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
 6: 0x104f98978 v8::ObjectTemplate::NewInstance(v8::Local<v8::Context>) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
 7: 0x104e241dc node::fs::FileHandle::New(node::fs::BindingData*, int, v8::Local<v8::Object>, std::__1::optional<long long>, std::__1::optional<long long>) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
 8: 0x104d869ec node::(anonymous namespace)::FdEntry::get_reader() [/opt/homebrew/Cellar/node/19.8.1/bin/node]
 9: 0x104d847b8 node::(anonymous namespace)::IdempotentDataQueueReader::Pull(std::__1::function<void (int, node::DataQueue::Vec const*, unsigned long, std::__1::function<void (unsigned long)>)>, int, node::DataQueue::Vec*, unsigned long, unsigned long) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
10: 0x104d86518 node::(anonymous namespace)::DataQueueEntry::ReaderImpl::Pull(std::__1::function<void (int, node::DataQueue::Vec const*, unsigned long, std::__1::function<void (unsigned long)>)>, int, node::DataQueue::Vec*, unsigned long, unsigned long) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
11: 0x104d84928 node::(anonymous namespace)::IdempotentDataQueueReader::Pull(std::__1::function<void (int, node::DataQueue::Vec const*, unsigned long, std::__1::function<void (unsigned long)>)>, int, node::DataQueue::Vec*, unsigned long, unsigned long) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
12: 0x104defcf8 node::Blob::Reader::Pull(v8::FunctionCallbackInfo<v8::Value> const&) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
13: 0x104fd8a58 v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
14: 0x104fd8858 v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, unsigned long*, int) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
15: 0x104fd82b8 v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
16: 0x104c733ec Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/opt/homebrew/Cellar/node/19.8.1/bin/node]
17: 0x104bf0064 Builtins_InterpreterEntryTrampoline [/opt/homebrew/Cellar/node/19.8.1/bin/node]
18: 0x104bf0064 Builtins_InterpreterEntryTrampoline [/opt/homebrew/Cellar/node/19.8.1/bin/node]
19: 0x104bf0064 Builtins_InterpreterEntryTrampoline [/opt/homebrew/Cellar/node/19.8.1/bin/node]
20: 0x104bf0064 Builtins_InterpreterEntryTrampoline [/opt/homebrew/Cellar/node/19.8.1/bin/node]
21: 0x104c28ab0 Builtins_GeneratorPrototypeNext [/opt/homebrew/Cellar/node/19.8.1/bin/node]
22: 0x104bee4f0 Builtins_JSEntryTrampoline [/opt/homebrew/Cellar/node/19.8.1/bin/node]
23: 0x104bee184 Builtins_JSEntry [/opt/homebrew/Cellar/node/19.8.1/bin/node]
24: 0x10509aa90 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
25: 0x10509b1a8 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
26: 0x1053a0c8c v8::internal::SourceTextModule::ExecuteModule(v8::internal::Isolate*, v8::internal::Handle<v8::internal::SourceTextModule>) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
27: 0x1053a067c v8::internal::SourceTextModule::InnerModuleEvaluation(v8::internal::Isolate*, v8::internal::Handle<v8::internal::SourceTextModule>, v8::internal::ZoneForwardList<v8::internal::Handle<v8::internal::SourceTextModule> >*, unsigned int*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
28: 0x1053a03e0 v8::internal::SourceTextModule::InnerModuleEvaluation(v8::internal::Isolate*, v8::internal::Handle<v8::internal::SourceTextModule>, v8::internal::ZoneForwardList<v8::internal::Handle<v8::internal::SourceTextModule> >*, unsigned int*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
29: 0x10539ff6c v8::internal::SourceTextModule::Evaluate(v8::internal::Isolate*, v8::internal::Handle<v8::internal::SourceTextModule>) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
30: 0x105355240 v8::internal::Module::Evaluate(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Module>) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
31: 0x104f849f8 v8::Module::Evaluate(v8::Local<v8::Context>) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
32: 0x104de085c node::loader::ModuleWrap::Evaluate(v8::FunctionCallbackInfo<v8::Value> const&) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
33: 0x104fd8a58 v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
34: 0x104fd8858 v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, unsigned long*, int) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
35: 0x104fd82b8 v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
36: 0x104c733ec Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/opt/homebrew/Cellar/node/19.8.1/bin/node]
37: 0x104bf0064 Builtins_InterpreterEntryTrampoline [/opt/homebrew/Cellar/node/19.8.1/bin/node]
38: 0x104c268b4 Builtins_AsyncFunctionAwaitResolveClosure [/opt/homebrew/Cellar/node/19.8.1/bin/node]
39: 0x104cc6e38 Builtins_PromiseFulfillReactionJob [/opt/homebrew/Cellar/node/19.8.1/bin/node]
40: 0x104c16834 Builtins_RunMicrotasks [/opt/homebrew/Cellar/node/19.8.1/bin/node]
41: 0x104bee3c4 Builtins_JSRunMicrotasksEntry [/opt/homebrew/Cellar/node/19.8.1/bin/node]
42: 0x10509aa60 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
43: 0x10509b1a8 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
44: 0x1050bdc7c v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
45: 0x1050bdaac v8::internal::MicrotaskQueue::PerformCheckpointInternal(v8::Isolate*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
46: 0x104d50ae8 node::InternalCallbackScope::Close() [/opt/homebrew/Cellar/node/19.8.1/bin/node]
47: 0x104e25864 node::fs::FileHandle::CloseReq::Resolve() [/opt/homebrew/Cellar/node/19.8.1/bin/node]
48: 0x104e26304 node::fs::FileHandle::ClosePromise()::$_0::__invoke(uv_fs_s*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
49: 0x104e182b4 node::MakeLibuvRequestCallback<uv_fs_s, void (*)(uv_fs_s*)>::Wrapper(uv_fs_s*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
50: 0x10784aff8 uv__work_done [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib]
51: 0x10784e3d0 uv__async_io [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib]
52: 0x10785e1e0 uv__io_poll [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib]
53: 0x10784e7d0 uv_run [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib]
54: 0x104d518a8 node::SpinEventLoopInternal(node::Environment*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
55: 0x104e60068 node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
56: 0x104e5fde8 node::NodeMainInstance::Run() [/opt/homebrew/Cellar/node/19.8.1/bin/node]
57: 0x104de6654 node::LoadSnapshotDataAndRun(node::SnapshotData const**, node::InitializationResultImpl const*) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
58: 0x104de67d8 node::Start(int, char**) [/opt/homebrew/Cellar/node/19.8.1/bin/node]
59: 0x1a2cd7e50 start [/usr/lib/dyld]

</details>

Why do you want to use node-fetch when deno have it built in already? ...so those NodeJS v18

Can we fist popup the screen on the Browser to tell where we want to save the file on the Client Side and then start write to it?

I first get data streamed to the Client, and few seconds later (even sometimes at the end) browser popups the screen to save the file on the Clients FS. I started this project with SocketIO.

In short I have this. Creating writeStream -> init getWriter -> socket emit "fileDownload" which creates createReadStream and sending chunks back to the client and client listen to them on "fileProgress".

 const fileStream = streamSaver.createWriteStream(this.fileToDownload.name, {
      size: this.fileToDownload.size, // (optional filesize) Will show progress
    });
    this.fStream = fileStream.getWriter();

    this.socket.emit('fileDownload', {
      fileName: this.fileToDownload.name,
    });

    this.socket.on(
      'fileProgress',
      (data: { percentage: any; bufferData: any }) => {
        this.downloadPercent = parseInt(data.percentage);
        this.fStream.write(new Uint8Array(data.bufferData));
      }
    );

Looks alright

No, it's not possible. to initiate the save dialog you actually have to start the download first. It's however possible with the new file system access api await showSaveFilePicker()

fyi, it's possible to change the hole Request / Response by using service worker.

Why

Reading the README, I got the sense that the purpose of the library wasn't clearly stated early on. This is an attempt to give an earlier insight into what it's purpose is.

Changes

• docs: Attempt to clarify the library's intent by providing an early ingress in the README

If you do have control over the server then i do recommend to use server tech to save a file rather then relying on StreamSaver.js which is intended for huge data generated on the client side, such as a camera recording.

all streamsaver really dose is emulating how a server traditionally saves a file using a service worker to emulate what browser/server have traditionally done for years

use object

JSON can also return only strings, booleans, numbers also. JSON isn't always a object

You could also do:

function visibilityChange() {
  return new Promise(rs => document.addEventListener('visibilitychange', rs, { once: true }))
}

just maybe i would apply it to a more generic util pattern to some like:

const once = (elm, type) = new Promise(rs => el.addEventListener('visibilitychange', rs, { once: true }))

// and use it as such:
const evt = await once(document, 'visibilitychange')
console.log(document.visibilityState)

I don't particularly see any need for a one-time awaitable event listener. it can already be solved in user land. i think there is other more important features that gets higher priority such as those thing that can't be polyfilled

By using <input type="number"> you would then precent the decimal separator to what the user is most comfortable pure visual only, but it gets normalized to dot . when accessing the value with javascript or posting the form to the backend

they would then also be able to use both comma and dot.

Hmm 🤔 seems to go a bit against my popup hack proposal. the blob fallback is the least favored method of saving data where it will store everything in memory until it can be saved.

the http solution is to create a popup window that can install a service worker via a secure domain. once the service worker is installed will it then transfer the readable stream over to the service worker and then close the popup window.

it's true that we eventually want to deprecate & archive this as NodeJS now has fetch built in. it's more or less our recommendation now, so not much new feature is put into our. but we strive for some backward comp for those who can't update their NodeJS version to newer version yet.

Perhaps this will be deprecated & archived when NodeJS v22 gets released and v18 becomes LTS When v20 becomes LTS, then maybe we can depend on the undici package instead as the lowest targeted supported version is 16 (at which point they introduced web streams)

our recommended way of importing a ESM only package is by using async import from a cjs project. or doing a simple but small wrapper of it:

const fetch = (...args) => import('node-fetch').then(({default: fetch}) => fetch(...args));

<!-- Thanks for contributing! -->

Purpose

Dummy change with fix: commit to trigger the release of https://github.com/node-fetch/node-fetch/pull/1696

Changes

Swapped RequestInfo | URL around to URL | RequestInfo 🤷‍♂️

Additional information

CI fail is irrelevant, same as before

Here are some reasons why using HTML5 constraint validation is a better choice than jQuery-validation:

Native support: HTML5 constraint validation is built into modern web browsers, which means it's faster and more efficient than jQuery-validation, which relies on external libraries.

• Accessibility: HTML5 constraint validation provides accessibility features that jQuery-validation may not. For example, it can work seamlessly with screen readers, providing important validation feedback to users who may have visual impairments.

• Easier to maintain: Because HTML5 constraint validation is built-in, it's easier to maintain than a third-party library like jQuery-validation. This can save time and resources in the long run.

• Cross-browser compatibility: HTML5 constraint validation is supported by all modern web browsers, while jQuery-validation may not be compatible with all browsers.

• Performance: HTML5 constraint validation is generally faster than jQuery-validation because it's built into the browser and doesn't require additional code to run.

• Scalability: HTML5 constraint validation can easily scale to support large and complex forms, while jQuery-validation may struggle to handle more advanced validation requirements.

• Future-proofing: HTML5 constraint validation is part of the HTML5 standard, which means it will continue to be supported and improved in the future. jQuery-validation may not be updated as frequently or may become obsolete over time.

Overall, HTML5 constraint validation is a better choice than jQuery-validation because it provides native support, accessibility, easier maintenance, cross-browser compatibility, improved performance, scalability, dynamic localized language that can more clearly describe the issue with a form of what it's, and future-proofing.

I think most of this can be inlined (coded by hand / plain vanilla javascript)

https://github.com/parshap/truncate-utf8-bytes/blob/c8fcebc8be093c8bd8db1e7d75c09b9fce7e4708/browser.js#L4

There is a simpler variant that dose not require any dependencies at all and is much much smaller and more cross env friendly:

var getLength = str => new TextEncoder().encode(str).length

how about just using:

<input type="number" class="left" id="field" name="field" value="44.451" required min="13" step="any">