Only compile interface and types without runtime code

[jvgomg]

I am interested in using Pkl to share static typings between Go and Typescript. I don't think I need the "evaluator" part of the code as I'm just interested in consuming the export interface Config code.

Is there a way to use pkl-gen-typescript and omit the imports, loadFromPath function and load function?

I can see there is a --settings-file option but snooping around generator-settings.pkl I cannot see anything relevant.

Maybe it makes sense to add a "definitions" mode which only generates .d.ts files? 🤔

Many thanks!

[jasongwartz]

Thanks for letting us know about your interest, @jvgreenaway! Feel free to come join us in the Pkl community Discord if you want to chat in more detail (both @jackkleeman and I are there, and there's a #bindings-typescript channel).

This is a great question and use-case, and one we've gotten once or twice before. I've also had times where I wanted to use Pkl as a 'lingua franca' for type definitions, that generates types for multiple languages, OpenAPI, etc. And I'm open to the idea of a "type definitions only mode" that doesn't include the evaluator imports.

The one issue we've had when discussing this before is that the generated types from pkl-gen-typescript are designed based on constraints that exist at runtime when evaluating Pkl code. For example, a Pkl Mapping or Map will type-gen an ES6 Map, not a Record; that's because Pkl allows any hashable object as a Mapping/Map key, not just strings. That can be annoying if you were hoping to access properties of the object using a subscript or dot-notation. When we discussed this last, I believe we came to the conclusion that it was not possible to satisfy both cases, so we stuck with type-generating an ES6 Map as an option that works correctly in both cases, and is slightly less ergonomic in the "using only the type generator but not the evaluator" case.

Another option if this constraint is unsatisfactory is generating a JSON Schema or OpenAPI spec from your Pkl module, and using code-generators with more customisation options.

If that constraint isn't a blocking issue for you, I'll talk over the idea in Discord and see if we think this is a reasonable addition.

[jvgomg]

@jasongwartz thank you very much for such an informative and helpful response. I am going to play with the the Mapping and Map types to fully understand what you are saying.

My use case is primarily to use the typealias type to generate union types, so that I have shared enums.

I'll come visit the Discord!

[jvgomg]

Another update my end - I am going to experiment with https://github.com/gzuidhof/tygo. This could fulfil my use case.