[recursive]

This 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://github.com/microsoft/TypeScript/issues/42219

[catapart]

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 it. I use it to inject HTML and CSS into templates. No reason it couldn't be used to inject a .proto file's contents into the inline template.

Again, you're technically correct! But a "import non js content" feature is a pretty solveable problem in TS. Maybe not at the language level, but at the implementation level, at least.

[phpnode]

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.

[bastawhiz]

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.

[phpnode]

You’re talking about runtime, I’m talking about at compile time

[bastawhiz]

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.

[phpnode]

I think you’re misunderstanding how this project works. The contents of that ?raw file are opaque to the typescript type system, it will see it as a `string`, not as the literal content of the file, therefore it cannot be parsed using template literal types as this project does and cannot be used to derive typescript types from protobuf files.

[yencabulator]

Even then, no import support -> must preprocess the .proto anyway.

Might as well do code generation at that point, it'd even be debuggable.

[ZitchDog]

The problem is that TypeScript is terrible at codegen, there are no standard extension points like we have with javac and others. So we are forced to do these crazy hacks at the type level rather than just generating types as you would in other languages.

[recursive]

Not familiar with the capabilities of javac, but in my imagination, I'm referring to a tool that runs prior to the typescript compiler, that just writes the intended source as text. Typescript never knew it wasn't in the repository or anything.

[cadamsdotcom]

That can be done with a `sed` call so it’s not a new dependency.