Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Embeddable configuration types #6

Open
Xe opened this issue Jul 20, 2023 · 2 comments
Open

Embeddable configuration types #6

Xe opened this issue Jul 20, 2023 · 2 comments

Comments

@Xe
Copy link

Xe commented Jul 20, 2023

I've been playing with TySON and I've been liking where this can go. I would like to be able to have my application ship a "config drive" or something in the form of an io.FS/embed.FS that's pre-baked with the type definitions. This would let me ship the types by default so I can write TySON configs like this:

import { Config } from "internal/config.ts";

export default {
  foo: "bar",
} satisfies Config;

What do you think about this? Shipping the types to editors would probably be a little bit hard, but I think it could be doable with some legwork.

@loreto
Copy link
Contributor

loreto commented Jul 20, 2023

I think we definitely need a way for applications to define types and easily make those types available.

I've been debating two options:

  1. Something like you are suggesting, where the application embeds the types and makes them available
  2. Support for url-based imports, so that the types can easily be published anywhere

For case 2, you could imagine creating your types under a github repo, let's say org/types-repo

And after you've published that repo you can now write the following config:

import { Config } from "github.com/org/types-repo/config.ts";

export default {
  foo: "bar",
} satisfies Config;

Would approach 2 also address your use case? Or are there reasons why you would prefer one approach vs the other?

@Xe
Copy link
Author

Xe commented Jul 20, 2023

I'd prefer embedding things directly into the application because adding a URL means that trying to validate configs in an environment like Nix builds (where there is no network stack) is nontrivial/annoying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants