[Feature Request] Shared defaults for every schema in a repository

Open
  • Is something wrong?
#1,146 2 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
json, node.js, typescript
Domain
tooling

Research direction

Start by reading the monorepo guide and the schema-loading code that handles imports, root decorators, and generator options; the issue does not name specific files or tests. Decide how repository defaults are discovered, combined with each schema's header, and overridden, then add coverage for multiple package depths and explicit opt-in behavior. Done means repository-wide defaults can be configured once and individual schemas can override them.

Written by the indexing model from the issue text.

Description

Description

A way to apply shared defaults to every schema in a repository (common imports, root decorators, generator options), without repeating them in each .env.schema.

Motivation

Following the monorepo guide (one schema per package, imports for what each needs), every package schema tends to start with the same header, for example:

# @import(../../.env.shared)
# @import(../../.env.secrets, enabled=forEnv(development))
# @generateTsTypes(path=./env.d.ts, auto=forEnv(development, test))
# ---

The relative paths differ by depth, and a change to the shared setup (a new generator option, a different auth import) means editing every schema. Varlock deliberately does not walk up to parent directories, which is reasonable as a default, so this would need an explicit opt-in.

Proposed Solution

For example, a varlock.defaults entry in the root package.json (or a root .env.defaults file that schemas opt into) listing imports and root decorators applied to every schema varlock loads within the repository, before the schema's own header, so a schema can still override any of them.

{
  "varlock": {
    "defaults": {
      "imports": [".env.shared", { "path": ".env.secrets", "enabled": "forEnv(development)" }],
      "generateTsTypes": { "path": "./env.d.ts", "auto": "forEnv(development, test)" }
    }
  }
}

The exact shape matters less than having one place for it.

Alternatives
  • Keep the repeated header in each schema (works, drifts).
  • A single root schema with tags and varlock.loadPath/filter per package, which loses per-package ownership of vars.
Additional Information

Pairs with importing workspace packages by name (#1140), which would remove the depth-dependent relative paths as well.

Dominant language
TypeScript
Stars
4.9k
Forks
140
Avg merge
2d 3h
Merged PRs (30d)
35

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dmno-dev/varlock

All issues in dmno-dev/varlock

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.