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.