resolved

I think that is the right fix

oh gosh ... all definition files are automatically generated per each CI build step or locally before pushing to npm. Apologies I should've mentioned this as this PR is quite some effort if it was fixed manually per each generated file, but next release will re-create again all files and all changes will be lost.

The files you need to eventually change are in the esm folder, not in the types one, as that's all automation.

Oh shoot thanks! This PR was fast - just a bunch of regex replaces - so nothing of value lost. I’ll make the correct changes when I’m back at my computer.

I noticed types/dom, types/html, types/interface, types/mixin, types/shared, types/svg,types/xml, and types/index.d.ts were not being auto-generated and haven't seen modifications in a very long time and the structure is the same as types/esm. I deleted these stale files.

At the moment there are a lot of types that are not right. Examples from the readme don't work.

I'm afraid this PR needs some linting adjustment or the CI won't be happy ... and I care about 100% code coverage and happy CI here. Please have a look and yes, exceptions accepted for linters!

I think this PR is good to go

oh gosh ... all definition files are automatically generated per each CI build step or locally before pushing to npm. Apologies I should've mentioned this as this PR is quite some effort if it was fixed manually per each generated file, but next release will re-create again all files and all changes will be lost.

The files you need to eventually change are in the esm folder, not in the types one, as that's all automation.

@WebReflection Hi, I want to contribute. Could you please explain what's the right way to include types? Are they generated from jsdoc comments?

@jeremy-rifkin

I think this PR is good to go

I just wonder once all "pretending to implement" classes are gone, if TS really helps out or it 'causes just confusion. There are things not really standard that might come up while using this project and I guess what are your thoughts there ... also, those two classes ... I think the implementation conforms with the standard? 🤔 are all implements needed to go?

@iMrDJAi yes, this JS project uses TSDoc and generates automatically types at build time.

I just wonder once all "pretending to implement" classes are gone, if TS really helps out or it 'causes just confusion. There are things not really standard that might come up while using this project and I guess what are your thoughts there ... also, those two classes ... I think the implementation conforms with the standard? 🤔 are all implements needed to go?

Thanks for taking a look! It may very well be these two classes do actually implement everything from their globalThis counterparts - I can re-introduce these implements annotations.

I think the one "pretending to implement" part remaining is whatever is returned by Document.defaultView. Alternatively to having it this function return a Proxy that's typed as typeof globalThis & { document: globalThis.Document & Document; }; we could make a proper class / type for exactly what a linkedom document view is. This would address the issue of non-standard things coming up.

this PR has conflicts ... please resolve those and I'd be happy to move forward, thanks!

no answer in years ... closing.