You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It is very common to define various helper schemas and internal data that should not be exposed to users.
CUE currently supports the ability to define hidden data - fields starting with a _, for example _#SomeSchema. This is not flexible enough for more common use cases, when cue should naturally be split up into separate packages. For example, I might want something like this:
In the above example, public may be a package we'd like to expose to consumers (either in the same repo, or soon via modules). strings is a package with helper schemas. We wouldn't necessarily like users to have access to strings.#EmailAddress, since it is usually ideal to restrict public APIs to the smallest possible surface - it makes refactoring more difficult/dangerous. Deciding what information/capabilities are exposed to users should be a conscious decision because of these consequences.
Describe the solution you'd like
I'm very satisfied with Golang's internal directory solution - it's very flexible and granular, and I haven't yet seen a case where it wasn't enough for managing encapsulation of functionality. I think it would be enough for cue to respect the internal directory (or something similar).
Describe alternatives you've considered
It's possible to keep utilities in the same consuming package as hidden data (prefixed with _) - but then "private" utilities cannot be shared across a module without a lot of duplication.
The text was updated successfully, but these errors were encountered:
NoamTD
changed the title
Support /internal/ directory or equivalent for encapsulating cue within a directory
Support /internal/ directory or equivalent for encapsulating cue data across dir hierarchy boundaries
May 8, 2024
Is your feature request related to a problem? Please describe.
It is very common to define various helper schemas and internal data that should not be exposed to users.
CUE currently supports the ability to define hidden data - fields starting with a
_
, for example_#SomeSchema
. This is not flexible enough for more common use cases, when cue should naturally be split up into separate packages. For example, I might want something like this:In the above example,
public
may be a package we'd like to expose to consumers (either in the same repo, or soon via modules).strings
is a package with helper schemas. We wouldn't necessarily like users to have access tostrings.#EmailAddress
, since it is usually ideal to restrict public APIs to the smallest possible surface - it makes refactoring more difficult/dangerous. Deciding what information/capabilities are exposed to users should be a conscious decision because of these consequences.Describe the solution you'd like
I'm very satisfied with Golang's
internal
directory solution - it's very flexible and granular, and I haven't yet seen a case where it wasn't enough for managing encapsulation of functionality. I think it would be enough forcue
to respect the internal directory (or something similar).Describe alternatives you've considered
It's possible to keep utilities in the same consuming package as hidden data (prefixed with
_
) - but then "private" utilities cannot be shared across a module without a lot of duplication.The text was updated successfully, but these errors were encountered: