Description
Describe the bug
This is a continuation of:
ryansolid/dom-expressions#277 (comment)
My goal is actually to replace all instances of DOM types (including HTMLElement etc) with my own custom type provided by a universal renderer, but this minimal repro establishes what the problem with that is.
The divide between 'solid-js' and 'solid-js/web' gives the impression that all web-related code is sectioned off into the web renderer, but that's only true at runtime, and not to typescript. The core JSX type is web-specific, and part of solid-js
. it gets used in a few places, including the type definition of things like the Component<>
type and the control flow primitives.
Because the runtime implementation is still doing the right thing, this can be worked around by allowing the dom types and then overriding them wherever you need to use them, but this comes at the cost of extensibility (can't make a solid-js library without depending on the web types) and maintainability.
Your Example Website or App
https://stackblitz.com/edit/solidjs-templates-s9fb1b?file=build.log&view=editor
Steps to Reproduce the Bug or Issue
- Remove 'dom' from your global type definitions. (in the repo that is done by
"lib: ['ESNext']"
in the tsconfig pnpm build
- observe build errors. examples:
node_modules/.pnpm/solid-js@1.7.6/node_modules/solid-js/types/jsx.d.ts(9,19): error TS2304: Cannot find name 'Element'.
node_modules/.pnpm/solid-js@1.7.6/node_modules/solid-js/types/render/hydration.d.ts(12,28): error TS2304: Cannot find name 'Element'.
Expected behavior
It should be possible to use the core reactive library without depending on the dom. likewise, it should be possible to use an entirely separate universal renderer without pulling in the dom types.
Screenshots or Videos
No response
Platform
all
Additional context
This is a larger task. It may require backwards-incompatible changes, and it would need input from core maintainers. I have some thoughts on how to approach this, I'll leave them in a follow-up comment