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.
> 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 c…
On the other hand, disallowing bypassing it limits what you can do. There's always a ceiling to what the compiler can figure out, and some very complex types can't be analysed statically right now. By allowing bypassing the system, I can still accurately type those functions and reap all the rewards, and I can make sure everything works by combining unit tests with type unit tests. If bypassing was disallowed, I'd be more limited in what I can express.
The criticisms were valid then, too. C (including the preprocessor of course) is still not fully parseable if you include things like token concatenation.
I make no representation as to soundness, then or now. Not till I figure out where my copy of the UNIX-HATERS Handbook has got to, at any rate. I've had cause reasonably recently to reread the X and sendmail chapters, not so much this one.
X and sendmail are not really very relevant today.
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.
You’re talking about runtime, I’m talking about at compile time
I make no representation as to soundness, then or now. Not till I figure out where my copy of the UNIX-HATERS Handbook has got to, at any rate. I've had cause reasonably recently to reread the X and sendmail chapters, not so much this one.
X and sendmail are not really very relevant today.
I make no representation as to soundness, then or now. Not till I figure out where my copy of the UNIX-HATERS Handbook has got to, at any rate. I've had cause reasonably recently to reread the X and sendmail chapters, not so much this one.
X and sendmail are not really very relevant today.
The mistakes embodied in both thus far look not just still relevant but positively timeless. Certainly, to judge by how often young people with no sense of their field's history recapitulate those mistakes.
It’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.
I was hoping to hear how are php types better than TS instead of another rant about how Rust is the greatest. Anyone? By the way, having lived in Scala 2 for a few years, Rust is half-assed. Type system leaks through the fingers when working with async collections. Future.sequence from Scala makes great cli apps. Scala collections are a work horse. The only thing from Rust I like is the shorthand question mark return…
lol. i mentioned rust as being the worst typed solution, to highlight ts is even beneath that.
This is super cool — love the zero-codegen approach. I’ve had to deal with codegen hell in monorepos where a tiny .proto change breaks half the pipeline. Curious how this handles more complex types like nested messages or oneof fields?
Also, been building something in a different space (LeetCode prep tool), but the idea of removing build steps for dev speed really resonates. Would love to see how this could plug into a lightweight frontend setup.
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.
You’re talking about runtime, I’m talking about at compile time
No, I'm talking about compile time. A loader at compile time (e.g., for webpack) takes whatever your import path is and translates it into something that can be used by the JavaScript application.
It would be awfully silly to do this at runtime because typescript doesn't exist at runtime, which is sort of the whole point of the library.