Hey there! The .../ import method is one I've seen used with broad success in projects small and large (and very, very large). That said, there are a few other ways to go about this:

Projects

One approach might be to break your configurations up into different projects and have them depend on each other as local dependencies. With this method, only the PklProject in each project needs to know the relative path on disk of its dependencies and modules need to know the relative path to their imports within each project.

In this this approach you might have a directory structure like this:

.
├── data
│   ├── actions
│   │   └── zdebug
│   ├── damageTypes
│   ├── runes
│   │   ├── 1x1
│   │   └── zdebug
│   └── schemas
│       │── effects
│       └── PklProject
├── PklProject         # relative local dependency on schemas/PklProject
...

Then, modules in any directory under data could import data/schemas/effects/targeting.pkl as @schemas/effects/targeting.pkl.

This approach has great editor support and is pretty flexible and is especially appealing if your schemas may be maintained/published separately from the rest of your data in the future.

Module path

If you're familiar with Java's class path or $PATH in your shell, Pkl's module path mechanism is very similar. The module path can be manipulated from the CLI, a PklProject file, or a language binding library so it can make moving modules around relative to each other a bit less brittle. This mechanism is particularly suited toward integrating Pkl into JVM-based applications, but can be used independently.

You can configure the modulepath by marking the directory as a resource root in IntelliJ or other JetBrains-based editors. However, there currently no support for it in pkl-lsp. This is something we're interested in adding in the future!