linkedom
linkedom copied to clipboard
WebReflection
Improve TS typing
This is an attempt to fix #167
I do not believe it's correct to suggest the DOMParser implements globalThis.DOMParser, the HTMLElement implements globalThis.HTMLElement, etc.
I think these changes should be ok given the goal of the library is to be close but not too close to the actual dom API.
Perhaps one of the original authors can lend insight into the original motivation for these implements annotations.
Todo:
- [x] Fix remaining errors
- [ ] Add an automated test case to ensure the library can be imported without errors
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!
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?
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!