Projects & Batch Mode

A registry of known projects lets sync/status run against every one of them at once with --all, instead of one project at a time via --cwd.

The project registry

lintsync projects add/remove/list manages the global registry.

lintsync projects add vuecraft ~/dev/vuecraft --tags type:site
lintsync projects add use-viewport ~/dev/npm/use-viewport --tags type:npm-package
lintsync projects list
lintsync projects list --tag type:site
lintsync projects remove vuecraft

A project's path is stored exactly as given (~/dev/vuecraft is kept literally, tilde and all) and only expanded to a real filesystem path at the point of actually operating on the project — during sync --all/status --all, not when it's added. Registering a name that's already taken is an error. None of the projects subcommands take --cwd — the registry itself is machine-scoped, not tied to any one project directory.

add <name> <path>

--tags <tags>

Comma-separated tags for this project, e.g. --tags type:site,team:frontend.

--registry <path>

Path to the project registry, if not the default.

--json

Machine-readable output.

remove <name>

--registry <path>

Path to the project registry, if not the default.

--json

Machine-readable output.

list

--tag <tag>

Restrict the listing to projects carrying this tag.

--registry <path>

Path to the project registry, if not the default.

--json

Machine-readable output.

Batch mode

Pass --all to sync or status instead of --cwd to run across every registered project:

lintsync sync --all                    # every registered project
lintsync sync --all --tag type:site    # only projects tagged type:site
lintsync status --all

--tag/--registry only do anything together with --all — passing either without it is silently a no-op, not an error. Batch runs are always non-interactive: a conflict is reported per project, never opens the TUI.

The overall exit code is 0 if every project succeeded, that same shared code if every project failed the same way, or 3 if projects disagreed — so a CI script can tell "uniform outcome" from "go look at the JSON" without parsing every project's result individually.

Global config and storage

Two files hold state that's global to the machine, not to any one project — the project registry and locally-saved presets. By default both live in the OS-standard per-user config directory, not inside LintSync's own install location or the current project:

OS	Default directory
Windows	%APPDATA%\lintsync\Config
macOS	~/Library/Preferences/lintsync
Linux	$XDG_CONFIG_HOME/lintsync (usually ~/.config/lintsync)

Inside it: projects.json (the project registry), presets.json (locally-saved presets), and config.json — LintSync's own main config, which you edit by hand:

{
  "presetsPath": "/somewhere/else/presets.json",
  "registryPath": "/somewhere/else/projects.json"
}

Either field is optional; set only the one you want to relocate. This config.json is itself found via, in order: the --config <path> flag, the LINTSYNC_CONFIG environment variable, then the OS-standard directory above. --config works in any position on the command line — before or after the subcommand name.

Precedence for where projects.json/presets.json actually live, highest first: a command's own --registry/--presets flag for that one invocation → registryPath/presetsPath in config.json → the OS-standard default. A missing config.json (or a missing/unreadable projects.json/presets.json) is not an error — LintSync just starts from empty/default state.