When using typescript, solid-js depends on DOM elements, even outside of "solid-js/web"

[Alloyed]

Describe the bug

This is a continuation of: https://github.com/ryansolid/dom-expressions/issues/277#issuecomment-1765059926

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

1. Remove 'dom' from your global type definitions. (in the repo that is done by "lib: ['ESNext']" in the tsconfig
2. pnpm build
3. 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

[Alloyed]

Approach 1. Move everything into solid-js/web

Any time the word JSX is used, that would need to be moved into the web folder, transitively. so that'd include the control flow components and core types, and so on. non-web users are left to fend for themselves. (you kind of have to do this anyways for a complete implementation: so far I've re-implemented and and I'm sure there's others)

Approach 2. Replace all instances of JSX types with generics

This would need a proof-of-concept before I could say this is actually possible, generics can be confusing! and this would likely reduce the readability of error messages for the vast majority of users. I would combine it with approach 1, where the variants exported by the web package are always the concrete types, for ergonomics reasons.

Approach 3. Return all dependent runtime functions from the createRenderer call

This has the benefit of only needing one generic, at the initial createRenderer method. but implies runtime changes that the other solutions would not.

[chiefcll]

Following... Relevant for https://github.com/lightning-js/solid which uses Universal Renderer and no DOM elements.