[BUG]: Type generation is not stable between environments

[apike]

varlock version

0.1.3

Steps to reproduce

Following out from a conversation with @theoephraim on Discord:

Currently, varlock generates types only as a side-effect of varlock load and varlock run. These commands generate different env.d.ts files depending on the environment they are run in. This causes various problems, which I'll give some examples of below.

What is expected?

These two improvements are closely related, but could potentially be done in two stages:

1. varlock should default to always generating the same types for a given codebase, regardless of what APP_ENV is set to when types are generated. This probably means that .local files or secret contents should not be able to modify types by default. It would be cool if the type generator considered all non-local .env.some_environment files and generated types that were a union of them, but I think it would be an improvement just to require you to manually define the .env.schema in a way that is compatible with the environment-specific files.
2. There should be a varlock generate-types command that has the above behaviour, and does not require access to secrets.

What is actually happening?

• If you follow the docs' proposal to gitignore env.d.ts, you then need to invoke varlock in each environment in order to generate the types in order for typechecking to pass.
  • Currently, varlock's type generation requires access to the secrets, which is inconvenient both in CI (where a typechecker shouldn't need access to API secrets) and in local dev (where an agent doing type checking could end up blocking on 1password access).
• Further, varlock's generated types currently vary depending on the environment they were last generated under, which can cause various issues.
  • For example, in one developer's .env.local, or when ENV=test there could be a different variable or rule that leads to typechecking passing or failing in one environment when it passes in others. This reduces the value of typechecking. For example, you might not discover until deployment that e.g. something invalid in your .env.some_environment causes typechecking to fail only in that environment, or allows a developer to push something that only typechecks cleanly with their .env.development.local files.
  • In a more abstract sense, it seems like one codebase should be able to rely on its type definitions being the same regardless of what valid ENV it is currently running in.
• If you attempt to work around some of this by committing the env.d.ts files, any subtle difference in what developer runs with varlock will cause unwanted git diffs of the types.
  • For example, if you make a change, commit, then run tests, those tests will likely run with an ENV of test (since they can't access 1password in CI), which is prone to generating slightly different types.
  • Or if two developers even have different comments in their .development.local files their varlock runs will generate conflicting types.
  • Currently we're also getting micro differences in the generated SVG paths that are embedded in the type files as well which is causing conflicts and thrash, but this would not be a problem if we didn't need to commit .env.d.ts for the reasons above.

So overall, there are various cases where type generation leading to different results depending on ENV isn't a good default.

System Info

Any additional comments?

I know this is halfway between bug and feature request, sorry!