3 ms·
So this is one area where I think TypeScript made a mistake: it added syntax that wasn't compatible with Javascript. This means you couldn't seamlessly support
by cletus 5y ago
So this is one area where I think TypeScript made a mistake: it added syntax that wasn't compatible with Javascript. This means you couldn't seamlessly support JS and TS with the same repo.
Wouldn't comments be a better solution to this given the legacy?
Here's what I think the type system should allow at a minimum:
1. Scalar types (number, string)
2. Common union types (eg something that could be a number or a string)
3. This is a big one: nullability should be part of the type system;
4. Object typing that includes mandatory and optional keys and their legal types;
5. Array types (generics);
6. Dictionary types (generics); and
7. An unknown type (like "mixed" in Hack).
Part of this is you need the option of preserving types at runtime and doing runtime type enforcement. This should be optional to generate a "debug" build and can be stripped out. You should be able to assert types as well as turn on automatic type checking on entry and exit to function calls as a method of finding bugs.
These errors should also be available as a warning (ie print to console.log) or an error (fatal).
Lastly, you should be able to easily write a type error handler to capture such violations.
- azangru 5y ago> you couldn't seamlessly support JS and TS with the same repo You could ... use a bundler, which would handle both js and ts files quite seamlessly.
- tomjen3 5y agoYou can easily work with both. Disable strict in the options (that is why it is there), then replace .js with .ts and it still works. Except now maybe you get some errors because of type inference that detects things like calling .toFixed on a string.