Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Yeah, I didn't get that either, when I read it, but I think what andrewbranch is talking about there[1] is that you might still be able to have problems importing TypeScript code that is using the new "bundle" module resolution — because it may allow other things that Deno doesn't allow.
I don't think he is talking about the problem we are, which is that because Deno requires the .ts extension, Deno doesn't actually work with standard, non-Deno TypeScript code (that imports other standard TypeScript code).
I mean, until now.
I will run some more extensive tests tomorrow or on the weekend, and maybe go comment there if I have something useful to say.
But anyway, it seems to me that if, like me, your problem was "Oh no, I cannot import my code into Deno because I cannot add the '.ts' to my imports without breaking it in other TypeScript use cases" then that problem is solved in TypeScript 5.
I have the same exact problem at work, except the monorepo is bigger and there are a lot of people who might not be excited to change all their import statements just so my own experimental Deno tools can use their code but... step by step. This seems like a big step for my personal TypeScript projects. :-D
[1]: https://github.com/microsoft/TypeScript/pull/51669#issuecomm...
Since `.ts` extensions were in alpha, our repo has been set up so that you can switch between Node and Deno seamlessly in-editor and continue developing with no config or source changes.
Personally, I found all the `npm` integration stuff to be a bit overkill for what we were looking for, and honestly Deno's network requests while installing from npm were constantly flaking out in our CI. We ended up just disabling it via Deno's `--no-npm` flag (https://github.com/denoland/deno/issues/17916) and reverting back to a simple set of import_maps to get the node deps we needed. Works like a charm!
Feel free to reference if it's useful:
https://github.com/arktypeio/arktype
> Decorators are an upcoming ECMAScript feature that allow us to customize classes and their members in a reusable way.
huh. i thought this was a bit early to do this but i checked (https://github.com/tc39/proposal-decorators) and looks like they've moved to stage 3. curious how this is going to change library/api design in the long term.
Since `.ts` extensions were in alpha, our repo has been set up so that you can switch between Node and Deno seamlessly in-editor and continue developing with no config or source changes.
Personally, I found all the `npm` integration stuff to be a bit overkill for what we were looking for, and honestly Deno's network requests while installing from npm were constantly flaking out in our CI. We ended up just disabling it via Deno's `--no-npm` flag (https://github.com/denoland/deno/issues/17916) and reverting back to a simple set of import_maps to get the node deps we needed. Works like a charm!
Feel free to reference if it's useful:
https://github.com/arktypeio/arktype
>If we could push JavaScript performance to be another order of magnitude faster
And it would speed up the TypeScript Compiler.
My bet is:
TypeScript typechecker in Rust:
https://github.com/dudykr/stc
You can do all you list with effect-ts/schema.
Arguably the highest quality TS lib out there.
https://github.com/Effect-TS/schema
Typescript for a while has focused on Stage 3 and Stage 4 proposals, so its "core elements" are almost all already in the language.
Unless you mean the type annotations itself? The good news there is that there is a Stage 1 proposal to take the Python/Ruby approach of bringing them into the language: https://github.com/tc39/proposal-type-annotations
Were that to happen, that proposal doesn't apply any type checking semantics for the browsers themselves and you would still want a type checker, such as Typescript, to actually check the types that are annotated. (Just as you want to run Mypy or Sorbet, respectively, in the cases of Python/Ruby.)
> how would the browser check and enforce my types?
If this is what you're looking for, you aren't going to get it with TypeScript, even if you could parse it in the browser. It might be possible to port or build a TypeScript parser that runs in the browser (it might even be done already) but this would mean sending a LOT of code over the wire for something that was designed as a static analysis tool.
You can use runtime validation libraries like https://zod.dev/.
JS will eventually include its own type system so that you will be able to write typed code and have it run in the browser. However, even then the types won't be checked at runtime. You'll still have to rely on a tool like `tsc` to type check your code.