Feature request: Better handling of user-defined modules #346

New Issue

adam · 2025-12-30T01:23:43+01:00

adam commented

2025-12-30 01:23:43 +01:00

Originally created by @Frnd-me on GitHub (Sep 16, 2025).

I'm using the Pkl Java bindings in a runtime system, where Pkl is the basis for a DSL.
For my DSL, I have a standard library, for which it is convenient to add a module like dsl:Something.

The Java bindings support this neatly: internally, the dsl: scheme gets translated to a classpath resource shipped with the runtime build. However, current support within IDEs and the CLI does not enable ergonomic handling of user-defined modules.

It would be very convenient if there were a way to define (globally, for instance, in Pkl settings) the handler for such schemes (for example, pointing to a URL where the same module can be fetched).

As far as I can tell from the documentation, this is currently possible at a project level, but that may not always be desirable; sometimes you want a global setting without needing to create a project.

Currently, the handling of schemes in the IDE plugins and CLI appears to be fairly static.

Full support throughout the toolchain would make user-defined module support more useful.

Proposed solution

Allow defining global scheme handlers in Pkl settings (CLI, IDE, or system-level config).
Ensure that the same scheme resolution works consistently across:
- CLI tooling
- IDE integrations (VSCode, IntelliJ, etc.)
- Runtime bindings (Java, etc.)

This would make user-defined modules a first-class feature in the Pkl ecosystem, improving ergonomics for DSLs and other custom uses of Pkl.

Originally created by @Frnd-me on GitHub (Sep 16, 2025). I'm using the Pkl Java bindings in a runtime system, where Pkl is the basis for a DSL. For my DSL, I have a standard library, for which it is convenient to add a module like `dsl:Something`. The Java bindings support this neatly: internally, the `dsl:` scheme gets translated to a classpath resource shipped with the runtime build. However, current support within IDEs and the CLI does not enable ergonomic handling of user-defined modules. It would be very convenient if there were a way to define (globally, for instance, in Pkl settings) the handler for such schemes (for example, pointing to a URL where the same module can be fetched). As far as I can tell from the documentation, this is currently possible at a project level, but that may not always be desirable; sometimes you want a global setting without needing to create a project. Currently, the handling of schemes in the IDE plugins and CLI appears to be fairly static. Full support throughout the toolchain would make user-defined module support more useful. ## Proposed solution - Allow defining global scheme handlers in Pkl settings (CLI, IDE, or system-level config). - Ensure that the same scheme resolution works consistently across: - CLI tooling - IDE integrations (VSCode, IntelliJ, etc.) - Runtime bindings (Java, etc.) This would make user-defined modules a first-class feature in the Pkl ecosystem, improving ergonomics for DSLs and other custom uses of Pkl.

adam closed this issue

2025-12-30 01:23:43 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pkl#346