Octri

CLI

Source maps

For toolchains that minify: JavaScript and Dart. Your build emits .map files that map mangled frames back to your original source, and this uploads them.

bash
octri-monitoring sourcemaps upload [paths...] [options]

paths defaults to the current directory and is scanned recursively for *.map.

Typical use

bash
octri-monitoring sourcemaps upload ./dist \
  --url https://monitoring.example.com \
  --environment "$MONITORING_ENVIRONMENT" \
  --release "$GIT_SHA"

With MONITORING_URL, MONITORING_TOKEN, and MONITORING_ENVIRONMENT in the environment, this collapses to:

bash
octri-monitoring sourcemaps upload ./dist

The release defaults to git rev-parse HEAD.

Your build has to emit maps

javascript
export default {
  build: { sourcemap: true },
};

Upload before you clean up

Maps only exist between build and deploy

Many pipelines build, deploy, and discard the workspace. If the upload runs after the artifacts are gone, it finds nothing and exits 1. Put it immediately after the build step. See CI setup.

Then delete them from the bundle

Do not serve maps to your users

Uploading maps to Octri makes traces readable in the dashboard. Serving those same files from your public web server hands your original source, comments and all, to anyone who opens devtools.

Upload them, then remove them from what you deploy.

Most hosts let you exclude them at deploy time. If yours doesn't, delete them after the upload:

bash
octri-monitoring sourcemaps upload ./dist
find ./dist -name '*.map' -delete

Dart

Dart minifies for release builds, so Dart is a sourcemaps language, not a sources one, despite compiling.

Verify first

bash
octri-monitoring sourcemaps upload ./dist --dry-run
text
[dry-run] would upload 3 map(s) for release 9f2c1ab:
  dist/index.js.map
  dist/vendor.js.map
  dist/runtime.js.map

Check the release matches what your SDK reports before you rely on it.

Source files

For compiled languages.
CI setup

Automate it.