3 ms·

I have been trying to get ts-node to work consistently for, like, five years and it’s always a fucking battle. I can only conclude that either I have miserably

I have been trying to get ts-node to work consistently for, like, five years and it’s always a fucking battle. I can only conclude that either I have miserably poor JavaScript skills or you only work on really simple code bases where this works, or some combination of the two. It’s not just ts-node—it’s Jest and other tools, it’s configuring ES modules to work in Node or deciding to use require(), it’s fine-tuning your TypeScript configurations (plural), it’s a bunch of stuff. > For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever already comes with typescript preconfigured if you select it. My experience is that this stuff is always on the verge of breaking when you integrate it with some new dependency, when you have needs that are slightly different from the mainstream use-cases that the developers envisioned, or when you start going through and updating your packages. I’ve been using JavaScript since the dark ages and the only way we can survive is by periodically cutting down some of the built-up complexity. We don’t need to cut it down for everyone, and not all at once, and no change is without its drawbacks. I’ve used create-react-app, I worked at a company that used machine learning in the JS build pipeline to do code splitting, I’ve used vanilla JS, and I’ve written some pretty damn cursed build systems for stuff like JS13K or 1K coding competitions. TypeScript sticks out as a rough spot in most build systems I’ve used, and the reason I still use it (most of the time—not always) is because the typechecking and IDE experience are just so damn good that it justifies the cost. > It seems quite extreme modifying javascript for this considering you still would want to remove types in order to reduce bundle size, and you would still need the actual compiler because you have things such as enums, annotations and more that JS doesn't support either. Not every change is applicable to all uses cases for everyone. That’s ok. If you decide to write TypeScript without enums you usually find that you don’t lose that much—it’s easy enough to do something like: type LogLevel = "error" | "warning" | "info"; Obviously this is not a one-size-fits-all trick, but I find myself using TypeScript enums less and less these days. There are also some dirtier TS tricks you can which let you create something kind of like Haskell’s newtype—pure type system stuff.

redox99 4y ago
The last point you mention actually makes me think this is probably a harmful change, that could have a chilling effect. People only wanting to use the subset of TS that runs as JS, could hamstring future TS features, as well as limit current features usage for no good reason.
- klodolph 4y ago
  I have the exact opposite opinion. TypeScript used to have more sugar, and that sugar had been removed and merged with the equivalent ES functionalities. Dig through old TS versions and you’ll find obsolete syntaxes or semantics that have been removed. Just to pick an example, TS had class before JS. IMO the ideal scenario here is that TS is just type annotations on top of JS, and any features you use which aren’t universally available, you polyfill/transpile as a separate step. This means TS is just types, and your transpired/polyfills are just transpilers/polyfills. To achieve that, TS classes are modified to match JS classes. My sense is that TS will not add new stuff not in JS any more. It’s simply not a direction TS is going. I also get the sense that enums are a mistake in TS’s design. TS in some sense is a reaction to the lessons learned from its predecessors, like CoffeeScript.
  - redox99 4y ago
    TS replacing it's own custom features if JS implements them is the correct move. But in my opinion they shouldn't hold back from adding features if they are good features. TS goal IMO should be to offer the best developer experience, while maintaining interoperability with the JS ecosystem. Not just limiting themselves to types. Why do you think enums are a mistake? Enums allow you to have autogenerated mappings from symbols to integers. You can't do that with types as you showed in your example.
    - klodolph 4y ago
      TS should absolutely hold back from adding new features that are not in JS. That’s TypeScript’s niche—we already have other languages with new features, TypeScript works better as a typing system and nothing else on top of an existing language. That’s why enum should be avoided in TS or added to JS. I can understand why people want TS to be a “better” language, but these days, ES is pretty good and a major part of TS’s success is that it follows JS semantics almost everywhere.
      - redox99 4y ago
        > we already have other languages with new features Not languages that can interoperate with JS the way TS does (except for flow and similar type checkers). TS success is that it's a superset of JS (unlike say CoffeScript). So you can throw some JS and it will be valid TS. The point of being a superset is that you can add new stuff. Types, enums, annotations. So the only argument why enums are bad except for that it's not in JS? Why does it matter, just because a JS developer has to learn more things if they switch to TS? The whole argument hinges on the premise that TS should not add anything that JS doesn't have except for types, but why is that?

redox99 4y ago

The last point you mention actually makes me think this is probably a harmful change, that could have a chilling effect. People only wanting to use the subset of TS that runs as JS, could hamstring future TS features, as well as limit current features usage for no good reason.

klodolph 4y ago
I have the exact opposite opinion. TypeScript used to have more sugar, and that sugar had been removed and merged with the equivalent ES functionalities. Dig through old TS versions and you’ll find obsolete syntaxes or semantics that have been removed. Just to pick an example, TS had class before JS. IMO the ideal scenario here is that TS is just type annotations on top of JS, and any features you use which aren’t universally available, you polyfill/transpile as a separate step. This means TS is just types, and your transpired/polyfills are just transpilers/polyfills. To achieve that, TS classes are modified to match JS classes. My sense is that TS will not add new stuff not in JS any more. It’s simply not a direction TS is going. I also get the sense that enums are a mistake in TS’s design. TS in some sense is a reaction to the lessons learned from its predecessors, like CoffeeScript.
- redox99 4y ago
  TS replacing it's own custom features if JS implements them is the correct move. But in my opinion they shouldn't hold back from adding features if they are good features. TS goal IMO should be to offer the best developer experience, while maintaining interoperability with the JS ecosystem. Not just limiting themselves to types. Why do you think enums are a mistake? Enums allow you to have autogenerated mappings from symbols to integers. You can't do that with types as you showed in your example.
  - klodolph 4y ago
    TS should absolutely hold back from adding new features that are not in JS. That’s TypeScript’s niche—we already have other languages with new features, TypeScript works better as a typing system and nothing else on top of an existing language. That’s why enum should be avoided in TS or added to JS. I can understand why people want TS to be a “better” language, but these days, ES is pretty good and a major part of TS’s success is that it follows JS semantics almost everywhere.
    - redox99 4y ago
      > we already have other languages with new features Not languages that can interoperate with JS the way TS does (except for flow and similar type checkers). TS success is that it's a superset of JS (unlike say CoffeScript). So you can throw some JS and it will be valid TS. The point of being a superset is that you can add new stuff. Types, enums, annotations. So the only argument why enums are bad except for that it's not in JS? Why does it matter, just because a JS developer has to learn more things if they switch to TS? The whole argument hinges on the premise that TS should not add anything that JS doesn't have except for types, but why is that?