6 ms·

Opening a can of worms for sure, but the reliance on Babel in the JS community is not a good thing to me. It's another reason why I prefer TypeScript, as in TSC

Opening a can of worms for sure, but the reliance on Babel in the JS community is not a good thing to me. It's another reason why I prefer TypeScript, as in TSC, not whatever equivalent babel happens to support.

Vinnl 6y ago
Would be interesting to hear what about it it is that makes it a bad thing - unless it's just the fact that it's a single project?
- mikewhy 6y ago
  I'm in the camp that Babel 6 was "useless by default" in the bad sense. It's great that when you use tsc you know exactly what features are supported or not, and don't have to change anything, or worry about compatibility between things. And I'm starting to all the babel-preset-* packages have just created a bunch of busywork for the maintainers. Then there's the issue of tooling requiring Babel. react-hot-loader should not require Babel. graphql tooling should not require Babel. I'd argue when you're knee-deep in Babel, you're no longer writing JS, you're writing BabelScript. Only your BS capabilities are different than Jane's BS capabilities, which are also different from Bob's setup over there.
  - Vinnl 6y ago
    Ah, I hear you - I'm not a fan of enabling a bunch of arbitrary Babel plugins either. But many metaframeworks (Next.js, Create React App) use Babel behind the scenes and use its TypeScript plugin for out-of-the-box TypeScript support. That's very useful, as long as the libraries you use don't use any of the Babel-incompatible features - which is most of the time, but not for TypeORM. So yes, it's exactly because I don't want to be configuring all kinds of language support for my projects that I'd recommend being able to work with (plain!) Babel with a TypeScript plugin.
lioeters 6y ago
I do agree that sticking to TSC keeps things a lot simpler, and that should be the default setup. Pandora's box has been opened though. Majority of the JS community seem to have adopted Babel in their workflow. Even as I question it, I must admit it's pretty sweet to have a transpiler in the buid toolchain. It frees one from the browser/backward compatibility question, more or less, and opens up the language to be extensible - for better or worse. For example, Babel macros ¹ is an interesting concept, using the language to extend the language during compile time. To bring it back to the topic at hand (PgTyped, Typesafe SQL) - one thing that I'd like to see in TSC is a way to output type definitions (either inlined metadata or external JSON schema), to be consumed for run-time type checking. That would "complete the circle" for me. TypeScript "compiler plugins" seem to be on the roadmap, or at least under consideration ². Some may see that as opening a proverbial can of worms, down a similar road to Babel. I wouldn't disagree, but it'd be so useful! ¹ https://github.com/kentcdodds/babel-plugin-macros https://github.com/kentcdodds/babel-plugin-macros ² https://github.com/Microsoft/TypeScript/issues/16607 https://github.com/Microsoft/TypeScript/issues/16607
- mikewhy 6y ago
  Oh agreed on all fronts :). Being able to add plugins is amazing, and there have been times I've almost added ttypescript for its plugin support. But then I remember the road that leads you down, and avoid it.
- alde 6y ago
  You might find io-ts [1] interesting. It allows to write composable parsers that do both runtime checks and have correct result types. Opt-in runtime checks for SQL queries are also on the roadmap for PgTyped. You are welcome to open an issue to track our progress there if you think this feature will be useful for you. [1] https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts
  - lioeters 6y ago
    Thank you - yes, I've dabbled with io-ts, though I'm still learning how to wield its power. > Opt-in runtime checks for SQL queries Ah right, I do see in the repo for PgTyped that it's on the roadmap. That does sound useful! I'm hoping that one of these days, TypeScript will support a more generic runtime type check, somehow closer to the language/TSC-level rather than userland libraries, plugins/transforms, or a parallel compiler/build step. At the moment, I use a fork of typescript-json-schema ¹ for my purposes. ¹ https://github.com/YousefED/typescript-json-schema https://github.com/YousefED/typescript-json-schema

Vinnl 6y ago

Would be interesting to hear what about it it is that makes it a bad thing - unless it's just the fact that it's a single project?

mikewhy 6y ago
I'm in the camp that Babel 6 was "useless by default" in the bad sense. It's great that when you use tsc you know exactly what features are supported or not, and don't have to change anything, or worry about compatibility between things. And I'm starting to all the babel-preset-* packages have just created a bunch of busywork for the maintainers. Then there's the issue of tooling requiring Babel. react-hot-loader should not require Babel. graphql tooling should not require Babel. I'd argue when you're knee-deep in Babel, you're no longer writing JS, you're writing BabelScript. Only your BS capabilities are different than Jane's BS capabilities, which are also different from Bob's setup over there.
- Vinnl 6y ago
  Ah, I hear you - I'm not a fan of enabling a bunch of arbitrary Babel plugins either. But many metaframeworks (Next.js, Create React App) use Babel behind the scenes and use its TypeScript plugin for out-of-the-box TypeScript support. That's very useful, as long as the libraries you use don't use any of the Babel-incompatible features - which is most of the time, but not for TypeORM. So yes, it's exactly because I don't want to be configuring all kinds of language support for my projects that I'd recommend being able to work with (plain!) Babel with a TypeScript plugin.

lioeters 6y ago

I do agree that sticking to TSC keeps things a lot simpler, and that should be the default setup. Pandora's box has been opened though. Majority of the JS community seem to have adopted Babel in their workflow. Even as I question it, I must admit it's pretty sweet to have a transpiler in the buid toolchain. It frees one from the browser/backward compatibility question, more or less, and opens up the language to be extensible - for better or worse. For example, Babel macros ¹ is an interesting concept, using the language to extend the language during compile time. To bring it back to the topic at hand (PgTyped, Typesafe SQL) - one thing that I'd like to see in TSC is a way to output type definitions (either inlined metadata or external JSON schema), to be consumed for run-time type checking. That would "complete the circle" for me. TypeScript "compiler plugins" seem to be on the roadmap, or at least under consideration ². Some may see that as opening a proverbial can of worms, down a similar road to Babel. I wouldn't disagree, but it'd be so useful! ¹ https://github.com/kentcdodds/babel-plugin-macros https://github.com/kentcdodds/babel-plugin-macros ² https://github.com/Microsoft/TypeScript/issues/16607 https://github.com/Microsoft/TypeScript/issues/16607

mikewhy 6y ago
Oh agreed on all fronts :). Being able to add plugins is amazing, and there have been times I've almost added ttypescript for its plugin support. But then I remember the road that leads you down, and avoid it.
alde 6y ago
You might find io-ts [1] interesting. It allows to write composable parsers that do both runtime checks and have correct result types. Opt-in runtime checks for SQL queries are also on the roadmap for PgTyped. You are welcome to open an issue to track our progress there if you think this feature will be useful for you. [1] https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts
- lioeters 6y ago
  Thank you - yes, I've dabbled with io-ts, though I'm still learning how to wield its power. > Opt-in runtime checks for SQL queries Ah right, I do see in the repo for PgTyped that it's on the roadmap. That does sound useful! I'm hoping that one of these days, TypeScript will support a more generic runtime type check, somehow closer to the language/TSC-level rather than userland libraries, plugins/transforms, or a parallel compiler/build step. At the moment, I use a fork of typescript-json-schema ¹ for my purposes. ¹ https://github.com/YousefED/typescript-json-schema https://github.com/YousefED/typescript-json-schema