Enabling TypeScript strict mode on Solid Playground

[mcjazzyfunky]

Would it be possible to activate TypeScript strict mode on the Solid Playground? It's completely confusing to work with TypeScript in non-strict mode (especially if you do not notice that you ARE in non-strict mode :wink:). Thanks a lot in advance.

[amoutonbrady]

I didn't investigate just yet but I can see three potentials outcomes:

• Strict mode can be enabled on a per file basis via a comment, much like the // @ts-check
• Strict mode can be toggled on and off via Monaco's API and therefore will be available as an option
• Neither of those two apply and we will most likely not support strict mode

No matter what there's very little chances that strict will be enabled by default. The reason TS is available is so that people can copy their source code into the playground and have it mostly working without removing all the TS stuff. I really don't want to force any TS stuff onto people.

Out of curiosity, what's the thing you are missing in strict mode that makes you confused? How does it deteriorate your experience in the playground?

[mcjazzyfunky]

Out of curiosity, what's the thing [...] that makes you confused

The other day, I erroneously claimed that the types of const [getX, setX] = createSignal<number>() are not proper in Solid, as the type of getX was currently Accessor<number> in Solid but should be Accessor<number | undefined>. The reason why I've claimed that was, that I've checked this in the Solid Playground and there the type hints told me indeed Accessor<number>. The problem, my bad - of course, was that the Solid Playground has not activated strict mode and therefore Accessor<number> and Accessor<number | undefined> are the same (but only in non-strict mode). I didn't notice and also did not expect that Solid Playground is working in non-strict mode and so I've basically wasted everybody's time with my comments. That's what I mean with "confusing".

[amoutonbrady]

Don't worry, you didn't waste anybody's time. This kind of discussion is how OSS projects grows.

I do understand your issue and I'll see if a solution is possible there according to the few points I mentioned above. Otherwise I might have a disclaimer somewhere on the playground.

Thanks for the feedback!

[swise0]

i think this feature is working right? because i had to start my script with a //@ts-nocheck comment

[edemaine]

Here's another example where strict: false confused me today. Without strict: true, TypeScript ignores undefined values. I was really confused how ctx had type Context<string> despite Solid defining export function createContext<T>(): Context<T | undefined>; (which adds an undefined option). Basically, strict: false made it hard to understand Solid's own TypeScript definitions.

I don't understand why strict: true isn't a good default. Sure, it may cause more squiggly red lines about type errors, but given that type errors are really just warnings (they don't prevent compilation or execution), does this hurt? I feel like it would only be helpful. If there aren't type annotations, many things will be typed any anyway, so I don't imagine a lot of additional squigglies (but I could be wrong about that).

[otonashixav]

I see that typescript errors can already be toggled via https://github.com/solidjs/solid-playground/commit/38a79782a529b020f6192ddb6f80ab6a42c46e2a. Given the intention of not forcing typescript onto users, wouldn't it make sense to disable typescript errors by default and enable strict mode?

[edemaine]

I'd still leave it on by default personally (after all, it's still just diagnostic), but strongly agree with enabling strict mode.

Perhaps "Display Errors" should be "Display Type Errors" or "Display TypeScript Errors" or even "Display [Type[Script]] Warnings"?

[edemaine]

Please can we have strict mode on by default? (when TS mode is on) It's just diagnostics, and it's extremely helpful for debugging TypeScript when e.g. designing new types for Solid. Without it, null is completely ignored.

Happy to submit a PR if that would help!