Hacker News Reader

Comment by recursive | Hacker News Reader

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

View on HN

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.

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

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.

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.

The loader proposal linked by the top level comment does not create strings, it imports them as the string literally type of their contents. That would absolutely 100% work with this project since the content of the imported file is available to the type system.

The reply with the typescript definition for ?raw is unrelated to this project and would neither solve the issue presently nor address it in the future. But if you implemented it in your bundler, it absolutely solves this problem exactly as described, because the imported file can have whatever boilerplate you want around it (like `as const`). This is something that exists and is usable today.

1. This whole subthread has been about the ?raw approach, not about a hypothetical feature that has not been agreed to yet.

2. Typescript runs before your bundler and has no idea what the bundler is doing, so any transformations you do there are invisible to it.

You keep telling me this is possible today, at this point I'd ask you to please prove it, because if it's true then that's very exciting and I have a bunch of use cases for it.

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

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

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.

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.

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

Reply on news.ycombinator.com