Web-specific version of `StructuredCloneable` type

[sindresorhus]

See: https://github.com/sindresorhus/type-fest/pull/897#issuecomment-2189741111

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• The funding will be given to active contributors.
• Thank you in advance for helping prioritize & fund our backlog.

[AviVahl]

The current version requires dom types: https://github.com/wixplosives/pleb/actions/runs/9767856252/job/26964079939?pr=732

Given this issue I'm not sure whether this was an oversight or done on purpose.

[AviVahl]

Or maybe File is only available with newer Node types. I use @types/node 18.x

[AviVahl]

Yep, newer @type/node@20 work. Sorry for the confusion.

[Emiyaaaaa]

@thecodewarrior

[Emiyaaaaa]

@sindresorhus Should we add @types/node 20 in package dependence, or remove File and Blob that depend on @types/node?

[sindresorhus]

I think it's ok to keep those as they are available in both Node.js and browsers. We should not add @types/node as a dependency.

[Emiyaaaaa]

I think it's ok to keep those as they are available in both Node.js and browsers. We should not add @types/node as a dependency.

But if user not install the @types/node or @types/node version less than 20, thay will get that error https://github.com/wixplosives/pleb/actions/runs/9767856252/job/26964079939?pr=732

So I think we should specify @types/node20 in dependencies. or remove File and Blob that require the @types/node.

[thecodewarrior]

We could probably add @types/node v20+ as an optional peer dependency

Something like this:

{
  "peerDependencies": {
    "@types/node": ">=20"
  },
  "peerDependenciesMeta": {
    "@types/node": {
      "optional": true
    }
  }
}

And it looks like we could lower it to "@types/node": ">19.2.0 || >=18.13.0 <19.0.0", if we're interested in the maximum possible compatibility:

• Blob was introduced in v15.7.0 and v14.18.0
• File was introduced in v19.2.0 and v18.13.0

/**
 * A [`Blob`](https://developer.mozilla.org/en-US/docs/Web/API/Blob) encapsulates immutable, raw data that can be safely shared across
 * multiple worker threads.
 * @since v15.7.0, v14.18.0
 */
export class Blob {
    // ...
}

/**
 * A [`File`](https://developer.mozilla.org/en-US/docs/Web/API/File) provides information about files.
 * @since v19.2.0, v18.13.0
 */
export class File extends Blob {
    // ...
}

[tao-cumplido]

I think it's ok to keep those as they are available in both Node.js and browsers. We should not add @types/node as a dependency.

But if user not install the @types/node or @types/node version less than 20, thay will get that error https://github.com/wixplosives/pleb/actions/runs/9767856252/job/26964079939?pr=732

So I think we should specify @types/node20 in dependencies. or remove File and Blob that require the @types/node.

I ran into this error and don't even use the StructuredCloneable type. I am writing a library that uses neither the DOM nor @types/node definitions. But since the StructuredCloneable is exported from index.ts, TS errors on not finding Blob nor File. Had to revert to ~4.20.1 for now.

[voxpelli]

Having same issue as @tao-cumplido – most my projects are currently failing type checks due to this.

Since the major version of @types/node adheres to the major version of node.js and since type-fest supports node.js >=16 it can't reference the File as neither @types/node@^16 or @types/node@^18 references it.

https://github.com/sindresorhus/type-fest/blob/60712f1d667a88dc2e3ae846281dd852f1303ac0/package.json#L16

Since most of my projects still support Node.js 18 I use @types/node@^18 in them, to get the types of the oldest version in my support range, and since I don't use skipLibCheck (classic reference to https://github.com/sindresorhus/tsconfig/issues/15 / https://github.com/voxpelli/tsconfig/issues/1) I get this issue, just like eg. @tao-cumplido and @AviVahl gets

(Also reminds me of https://github.com/sindresorhus/type-fest/issues/809, which I guess is a bigger issue for those of us that don't use skipLibCheck, as we get struck by issues like this, and I can't use skipLibCheck as I need the .d.ts files that I write myself to be validated)