[Feature Request] Import workspace packages by name, and audit the packages an app imports

Open
  • Is something wrong?
#1,140 1 comment 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
39/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
bun, node.js, typescript
Domain
backend, devtools

Research direction

Start by reading the monorepo guide and tracing how @import() resolves paths, how varlock audit scans directories, and how varlock flatten rewrites imports. The issue names Bun's Bun.Transpiler.scanImports and Bun.resolveSync as examples for workspace graph discovery. Done means package-name imports resolve from the importing file and audit can report env reads from imported workspace packages against the app schema.

Written by the indexing model from the issue text.

Description

Description

Two related gaps for monorepos where packages own their env vars (the per-package schema layout from the monorepo guide):

  1. @import() only takes file paths, so an app imports each workspace package's schema by relative path: # @import(../../packages/db/).
  2. varlock audit only scans the directories it is given. An app whose code reaches a package's code through a workspace import has no way to audit that package's env reads against the app's schema, so a package schema the app forgot to import goes unnoticed.
Motivation

In a Bun monorepo with several apps and packages, each package declares its own vars and each app imports the schemas of the packages it uses. The relative paths duplicate what package.json already says (the app depends on @acme/db), and break when a package moves. For the audit we wrote a 78-line script that walks each app's module graph (Bun.Transpiler.scanImports, Bun.resolveSync), collects the workspace packages it reaches, and runs varlock audit <app> <package dirs...> per app. That script is the one piece of custom env tooling left.

Proposed Solution
  • Let @import() take a package name and resolve it the way the runtime would, from the importing file: # @import(@acme/db) imports that package's directory (its .env.schema plus env files), the same as @import(../../packages/db/) today. pick/omit/enabled/allowMissing work as for paths.
  • With that, varlock audit knows which package directories belong to a schema and can scan them alongside the app's own code, so a var read in @acme/db but missing from the app's resolved schema is reported. A flag or root decorator could turn this on (for example varlock audit --imports).
Alternatives
  • Keep relative paths and a hand-written import-graph script per repo (what we do now).
  • package.json varlock.loadPath with tags from a single root schema; this loses per-package ownership of vars.
Additional Information

varlock flatten already rewrites import paths for container builds, so package-name imports would need the same treatment there.

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.