Importing types from @types/web package

[thw0rted]

The @types/web package typings are published as a lib -- they don't declare any module, they don't import or export anything. You can include them using a triple-slash comment, but I don't think it's possible to import individual types. It would be helpful to be able to write import type {Element} from "web"; without having to pollute the whole global namespace with every web type.

[orta]

I could imagine this as another potential export from this repo, its use case is pretty niche though IMO because you don't want to be including this in an environment which has dom added globally because the versions could easily be mismatched

I think it's very likely that TS could never move away from vending the interfaces globally because of ecosystem breakage, which means you'd have to be quite delicate in how a project using this would be set up

[saschanaz]

Certainly need to think what would happen when some library exposes some type from modular @types/web@0.0.99 and the global enviroment has @types/web@0.0.100. But I think that's what already happening from DefinitelyTyped. 🤔

[thw0rted]

I mean, at least any mechanisms for pinning a package to a version exist -- it wouldn't be crazy to ship mylib with a peerdep of "@types/web": "^0.12.34" (though, granted, we still don't have optional peerdeps). With built-in lib types, the library has absolutely no control over which definition of, say, globalThis#Blob it gets. (Ask me how I know...)

[thw0rted]

Maybe this isn't as important as I thought, because I'm not sure Node's "DOM compatible" APIs actually are 100% compatible. More at DefinitelyTyped/DefinitelyTyped#59905...

[thw0rted]

I just updated the issue I linked a few months ago. It looks like as of Node v18, they're putting their "web compatible" types (or at least Blob) into the global namespace. Does anybody from the TS team have plans/ideas how to handle this? There are a lot of projects out there with both @types/node and lib: ['dom'] and I don't think there's going to be any putting that genie back in the bottle, so the types will just have to get along with each other somehow.

[thw0rted]

Per my update on the linked issue, I'm increasingly worried that Node is going to keep adding "compatible" interfaces in the global namespace, which actually wind up having some Node-exclusive properties or methods if you drill down far enough.

Assuming this is the case, it would be great if someone on the TS team could take an interest in improving Node typings. At the moment, they're on a tightrope, constantly trying to be as accurate as possible without becoming fundamentally incompatible with lib-dom. It's only going to get harder.

[piranna]

This can help us to unblock DefinitelyTyped/DefinitelyTyped#60924 without needing to duplicate types or re-invent the wheel...

[MKRhere]

This has another purpose when working with Deno - there's no decent way to build an isomorphic project with multiple platform globals checked for at runtime. We went with fetching lib.dom.d.ts and scripting it to become importable.
https://github.com/feathers-studio/hyperactive/blob/93847e9495c4de8c68a320ea2a0b442552b2fc5a/hyper/vendor/dom.slim.ts

Usage:
https://github.com/feathers-studio/hyperactive/blob/93847e9495c4de8c68a320ea2a0b442552b2fc5a/hyper/render/dom.ts#L8

guessEnv actually checks at runtime, so it's safe, and dom types are contained within this one file.

I hope this can add motivation towards modular @types/web!

[felixfbecker]

This can help us to unblock DefinitelyTyped/DefinitelyTyped#60924 without needing to duplicate types or re-invent the wheel...

It wouldn't need to export anything to help with fetch in Node, but it would just need to be split into multiple packages like @types/web-fetch that becomes a dependency of @types/web but can also be added as a dependency to @types/node (from v16 onwards) individually.

[MKRhere]

@felixfbecker This solves a very specific issue for fetch, while you can solve a very generic issue with this proposal.