feat: add reset=true arg to @generateTypes

[Raigato]

Summary

• Adds a strict=true argument to the @generateTypes decorator
• When set, the generated env.d.ts adds a [key: string]: unknown index signature to both ProcessEnv and ImportMetaEnv, making TypeScript flag accesses to undeclared env variables as unknown rather than implicitly allowing them
• Usage: @generateTypes(lang=ts, path=env.d.ts, strict=true)

[changeset-bot]

🦋 Changeset detected

Latest commit: bfd7c1d

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

This PR includes changesets to release 12 packages

Name	Type
varlock	Minor
@varlock/astro-integration	Major
@varlock/nextjs-integration	Major
@varlock/vite-integration	Major
@varlock/1password-plugin	Major
@varlock/aws-secrets-plugin	Major
@varlock/azure-key-vault-plugin	Major
@varlock/bitwarden-plugin	Major
@varlock/google-secret-manager-plugin	Major
@varlock/hashicorp-vault-plugin	Major
@varlock/infisical-plugin	Major
@varlock/pass-plugin	Major

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

[theoephraim]

Concept makes sense but not sure about the "reset" naming. Maybe something like processEnv=strict and importMetaEnv=strict. Im also thinking this would allow you to to say processEnv=false to turn off include those types at all.

Also curious - why not use the import { ENV } from 'varlock/env' - this way of accessing things is already strict.

[Raigato]

Concept makes sense but not sure about the "reset" naming. Maybe something like processEnv=strict and importMetaEnv=strict. Im also thinking this would allow you to to say processEnv=false to turn off include those types at all.

Also curious - why not use the import { ENV } from 'varlock/env' - this way of accessing things is already strict.

Indeed, was not sure about the naming either, thought it like a css reset but strict makes sense. Dunno about the ability to let the types free wheeling by not generating them. IMO, the unknown types should be the default but it may be too opinionated.

Concerning the ENV, there are 2 reasons to not use it on my side:

• I work with a lot of external contributors so I tend to keep things very native. For example, if a dev comes by and does not know much about the stack, they will immediately notice something isn't right when using a env variable the native way through process.env or import.meta. Also I think it is a nice approach with LLMs so they do not have to bloat context with doc fetching/grep searching
• I remember doing something like this with zod in Next.js and it became really messy with the public and private env dichotomy but pretty sure it was skill issue