@errortracking/cli

Command line tool for uploading source maps to Error Tracker, so browser errors resolve to your original source code instead of minified output.

Install

npm install --save-dev @errortracking/cli

Or run without installing:

npx @errortracking/cli upload

Quick start

Create an errortracking.config.js in your project root:

// errortracking.config.js
module.exports = {
  apiKey: "et_live_your_key_here",
  apiUrl: "https://error-tracking-server.onrender.com",
  dir: "./dist",
};

Then run:

errortracking upload

The CLI scans your build folder, finds all .js.map files, and uploads them. The release defaults to the version field in your package.json.

Auto-upload on every build

Add the upload step to your build script so maps are always in sync:

{
  "scripts": {
    "build": "vite build && errortracking upload"
  }
}

Config file

The CLI looks for config in this order, stopping at the first file found:

1. errortracking.config.js (JS module, module.exports = { ... })
2. errortracker.json (plain JSON)
3. .errortrackerrc (plain JSON)

All four fields are optional in the config file; anything not set falls back to flags, environment variables, or the defaults below.

All flags

errortracking upload [dir] [options]

| Flag / argument | Description | | --------------- | -------------------------------------------------------------------- | | [dir] | Build folder to scan for .js.map files. Default: ./dist | | --release | Release version tag (e.g. 1.0.0). Default: package.json version | | --api-key | Project API key | | --api-url | Error Tracker backend URL | | --force | Upload even when more than 200 maps are found (see below) |

Priority order

For each setting, the CLI uses the first value it finds:

flag > environment variable > config file > default

Environment variables (note: lowercase errortracking_ prefix, as the code reads them):

| Variable | Description | | ------------------------- | ------------------- | | errortracking_API_KEY | Project API key | | errortracking_API_URL | Backend URL |

--force: when to use it

By default the CLI refuses to upload if it finds more than 200 .js.map files, because that usually means you pointed it at the project root instead of the build output folder. Fix: pass the correct directory (e.g. ./dist).

Use --force only when you have genuinely confirmed that you have more than 200 real build-output maps and still want to upload all of them. Do not use it to silence the warning when you have the wrong folder -- you will flood the server with maps from node_modules and hidden directories.

# correct folder, happens to have >200 maps -- use --force
errortracking upload ./dist --force

# wrong: silencing a wrong-folder mistake
errortracking upload . --force   # don't do this

Release must match

The --release you upload under must match the release you pass to init() in @errortracking/browser-sdk. If they differ, errors arrive but still show minified locations.

What gets uploaded

• Only .js.map files (TypeScript declaration maps like .d.ts.map are skipped)
• node_modules, .git, .next, .cache, and hidden directories are never scanned