@required - env() helper

[theoephraim]

First steps towards #119

This adds a new helper to set item required-ness based on the current env (as set by @envFlag)

Some notes:

• not sure about the env() name, could be ifEnv isEnv forEnv
• value can be a single env, or multiple
• works for both @required and @optional
• if the value is dynamic, we must respect that in type generation

In an ideal world, we'd handle any arbitrary logic here, and likely unify our resolver functions (which are used for item values) with our decorator values. However this introduces a lot of complexity, because now items can be dependent on each other in new ways, and the resolution process would need to handle that.

For now, we are using a much more limited subset. Using the envFlag is totally safe, because we always resolve that up front, so it does not introduce any new ordering / dependency issues. We likely want to add a few more helpers here, but they will likely have additional limitations, which will allow us to keep things a bit simpler.

[changeset-bot]

🦋 Changeset detected

Latest commit: 65c9466

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
varlock	Patch
@varlock/astro-integration	Patch
@varlock/nextjs-integration	Patch
@varlock/vite-integration	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/dmno-dev/varlock@136

npm i https://pkg.pr.new/dmno-dev/varlock/@varlock/astro-integration@136

npm i https://pkg.pr.new/dmno-dev/varlock/@varlock/nextjs-integration@136

npm i https://pkg.pr.new/dmno-dev/varlock/@varlock/vite-integration@136

commit: 65c9466

[philmillman]

I think I like forEnv(...) as it seems the most semantic

[philmillman]

🚢