This makes me wonder if this the way to do schema generation in Typescript. I’m working on Typeconf, and we have a separate step for translating Typespec schema to Typescript, it’ll be cool if we could just load typespec directly.
Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
41–50 of 80 posts
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#42This requires the whole `.proto` declaration inline in source a string constant. I'm not holding my breath on "Import non-js content"[1] getting approved, so that means you still have to use another build dependency, or manually keep the .proto files synchronized across multiple sources truth. In that light, it's not clear when this would be a benefit over straight-forward code gen. Cool POC hack though. [1]: https:/…
It's true that it's another dependency, but this is the entire contents of a file I drop into my project root called `raw-loader.d.ts`: ``` declare module '*?raw' { const rawFileContent: string export default rawFileContent } ``` Then, when I add the file to my types property array of my tsconfig's compilerOptions, I can import anything I want into a typescript file as a string, so long as I add "?raw" to the end of…
right, but typescript sees that as a `string`, and not a string literal and thus cannot be parsed by this project or others like it.
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#43Earlier quoted context omitted.
I don't disagree! It's just the fact that it has to be transpiled to JS that's the problem, because it means none of the types are "real"; there's no runtime assurance that a string is actually a string. TS is great and I'd never go back to JS, but it's ultimately a bandaid. Native TS support in browsers is probably never going to happen, though, sadly. Imagine if WASM were supported natively instead, with browsers e…
I think you're conflating cause and effect in several cases. TypeScript can't be thought of, and would never exist, independently from JavaScript like you're trying to do. TypeScript wasn't created separate from JavaScript and then chose JavaScript as a backend. TypeScript only exists to perform build-time type checking of JavaScript. There wouldn't be a TypeScript that compiled to something else, because other langu…
I was thinking more along the lines of a TypeScript-like compiled language. For example, AssemblyScript[0] but with the web APIs added back in. (Personally I'd prefer C# or Rust, but you know most devs will want to keep using JS/TS.) WASM isn't natively supported in the way that I'm wishing it were, though; you still have to use JS to bootstrap it, and JS to call back into web apis. In my ideal world, I'd want to be able to compile
public static void Main() { Document.Body.Append(new Div("hello world")); }
(Btw when I said "separate runtime type checking" I didn't mean language-level; I was referring to the validation libraries and `typeof`'s that are required today since TS types obviously no longer exist after build. If it were a real static language, then of course you can't store a bool in a string in the first place.)
[0]: https://www.assemblyscript.org/ (Porffor looks neat too. Wonder if it could be useful in plugin architectures? E.g. plugins can written in JS, and the program only needs a WASM interpreter. I'll bookmark it. Thanks.)
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#44Earlier quoted context omitted.
TypeScript does an amazing job at describing the types of real-world JavaScript. It's incredibly good, and very useful, even in the face of extremely dynamic programs. The fact that it can describe transforms of types, like "this is a utility that adds an `xxx` prefix to every property name" is frankly unparalleled in mainstream languages, but more importantly lets us describe patterns that come up in real-world JS p…
I don't disagree! It's just the fact that it has to be transpiled to JS that's the problem, because it means none of the types are "real"; there's no runtime assurance that a string is actually a string. TS is great and I'd never go back to JS, but it's ultimately a bandaid. Native TS support in browsers is probably never going to happen, though, sadly. Imagine if WASM were supported natively instead, with browsers e…
> there's no runtime assurance that a string is actually a string.
As someone who's written a lot of Typescript in fairly large projects: in practice this isn't really an issue if you
1. ban casting and 'any' via eslint,
2. use something like io-ts at http api/storage boundaries to validate data coming in/out of your system without a risk of validator/type mismatch.
But you have to have total buy in from everyone, and be willing to sit down with new devs and explain why casting is bad, and how they can avoid needing that eslint suppression they just added to the codebase. It certainly would be easier if it just wasn't possible to bypass the type system like this.
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#45The fact that the source is so small is wild. I would have expected a huge convoluted parsing library implemented in types. On the other hand, the fact that this is even possible is more wild. Instead of replacing JS with a proper statically-typed language, we're spending all this effort turning a preprocessor's type system into a turing-complete metalanguage. Pretty soon we'll be able to compile TypeScript entirely…
TypeScript does an amazing job at describing the types of real-world JavaScript. It's incredibly good, and very useful, even in the face of extremely dynamic programs. The fact that it can describe transforms of types, like "this is a utility that adds an `xxx` prefix to every property name" is frankly unparalleled in mainstream languages, but more importantly lets us describe patterns that come up in real-world JS p…
Typescript is so much better than almost every other dependently typed language in terms of expressing these things[0], and it's still kind of miserable.
We still have a long way to go in figuring out how to get our type systems to be easy enough to use to where this stuff doesn't surprise people anymore (because it shouldn't! identifier manipulation should be table stakes and yet)
[0]: modulo soundness of course! Though I don't think that's intrinsic to the expressiveness
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#46Earlier quoted context omitted.
I don't disagree! It's just the fact that it has to be transpiled to JS that's the problem, because it means none of the types are "real"; there's no runtime assurance that a string is actually a string. TS is great and I'd never go back to JS, but it's ultimately a bandaid. Native TS support in browsers is probably never going to happen, though, sadly. Imagine if WASM were supported natively instead, with browsers e…
> there's no runtime assurance that a string is actually a string. As someone who's written a lot of Typescript in fairly large projects: in practice this isn't really an issue if you 1. ban casting and 'any' via eslint, 2. use something like io-ts at http api/storage boundaries to validate data coming in/out of your system without a risk of validator/type mismatch. But you have to have total buy in from everyone, an…
I know, but it's that last bit: it shouldn't be possible to bypass it. C# actually got itself into a similar issue despite being a proper static language, because when it added "nullable reference types" (where you can't assign null to a variable of type `Foo` unless it's explicitly typed as `Foo?`) they did it like TypeScript using purely static analysis to avoid having to change the language at a lower level (for compatibility).
Even though it works 99% of the time, just like in TS you can occasionally run into a bug because some misbehaving library handed you a null that it said can't be a null...
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#47It’s pretty rad how flexible template literal types are, but I can’t imagine wanting this kind of shenanigans hanging out in a production app slowing down compile times. I prefer to define types in TypeScript and generate proto from that, since the TypeScript type system is so much more powerful than the Protobuf system. Types are much more composable in TS.
What do you use to go from ts->pb?
[deleted]
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#48It’s pretty rad how flexible template literal types are, but I can’t imagine wanting this kind of shenanigans hanging out in a production app slowing down compile times. I prefer to define types in TypeScript and generate proto from that, since the TypeScript type system is so much more powerful than the Protobuf system. Types are much more composable in TS.
What do you use to go from ts->pb?
I have an old public version here: https://github.com/justjake/ts-simple-type/blob/main/src/com...
Ultimately i decided ts-simple-type is too difficult to maintain, so now I just use the TypeScript compiler API directly to introspect types and emit stuff, but most of that code is private to Notion Labs Inc
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#49I wish there was other way around. infer binary encoding from native types
Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs
#50Earlier quoted context omitted.
It's true that it's another dependency, but this is the entire contents of a file I drop into my project root called `raw-loader.d.ts`: ``` declare module '*?raw' { const rawFileContent: string export default rawFileContent } ``` Then, when I add the file to my types property array of my tsconfig's compilerOptions, I can import anything I want into a typescript file as a string, so long as I add "?raw" to the end of…
right, but typescript sees that as a `string`, and not a string literal and thus cannot be parsed by this project or others like it.
That's simply not true. A loader can do whatever it wants. It translates the raw file contents into anything. Granted, at that point you'd might as well have the loader just be a traditional protobuf compiler, but the point still stands that this isn't an invalid solution.