-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better usability when type checking #53
Comments
Ok, I have been doing some looking into this and research, a few comments:
|
Another point I forgot:
|
I think whatever solution we go with should type check with the language server and work in Deploy without needing a tsconfig.json or other setup configuration. I've only been looking at this today and a bit yesterday so I'm probably missing a lot and more than likely don't understand something, but here are my initial thoughts (apologies for over explaining, but it's just to get verification I understand what's going on). JSX - Type Checking and CLI & Deploy Differences As discussed, JSX right now in Deploy and the CLI are different because Deploy uses the jsx factory This means users who are using the language server will not get a compile error when they use react even though what they're doing would not work on Deploy (they should be forced to specify Additionally, in order for people to get Deploy JSX to type check happily in the language server and with /** @jsx h */
/** @jsxFrag Fragment */
import { h, Fragment } from "https://deno.land/x/sift@0.3.0/mod.ts"; Or add a tsconfig.json that specifies these options. This would be resolved by the CLI breaking to use My personal opinion is that I don't like how JSX requires functions to be imported and then magically calls them. I wish we could work towards JSX being transformed to a standalone object (ex. of type Type Errors Ideally the code should type check for the language server, I don't believe we should reply on a wrapper in deployctl as that does not play well with the code type checking in the language server. Instead, we may want to consider figuring out what triple slash directives might make the most sense and recommend people add that to their code.
It doesn't seem like we should recommend this to users unless:
Both these issues seem more easily achievable and less error-prone by telling users to run their Deploy code through a tool like deployctl. dom types and Deno deploy The current recommended way to use a library that relies on This seems less than ideal as Edit: it would be nice if TS moved DOM types out https://twitter.com/sanders_n/status/1407030997686702081
I agree. |
I think this is misguided. All this would do is fracture further an already fractured ecosystem and further make Deno incompatible with other ecosystems. What you don't like is JSX. Transpiling to something other than |
You're not wrong 😅 and yeah I agree that reducing the magic of JSX would be too disruptive and agree that it wouldn't be good for the end user experience given the current state of the system. I guess JSX is just what JSX is at this point.
Hmmm... yeah I prefer people importing it so we don't risk breaking something for them in the runtime. Anyway, yeah denoland/deno#11186 looks like a good way forward. |
Thanks for contributing by opening an issue. This project is being archived because you can now use If you have feedback about Deno Deploy, please open an issue on this repo: https://github.com/denoland/deploy_feedback |
however works with
The text was updated successfully, but these errors were encountered: