dryRun Command: Troubleshooting and Validation
Validate your slnodejs setup locally, review dryRun output, and fix common configuration issues before CI.
Use dryRun to validate your slnodejs setup locally before you spend time on CI runs.
It helps you confirm that SeaLights scans the right files, resolves the right sources, and catches configuration issues early.
dryRun does not replace your CI integration.
It creates a local report only and does not send data to SeaLights.
When to use dryRun
Use dryRun during first-time setup, when the scan includes unexpected files, when source maps do not resolve as expected, or when NYC coverage paths do not line up with the build scan.
It is the fastest way to see what the agent will analyze before you move the flow into CI.
Before you start
Make sure the slnodejs agent is installed. See Downloading the Node.js Agent.
If you scan a minified front-end build, keep the *.js.map files next to the built JavaScript files.
The source maps must point to the correct source files and include column information.
Run the command
Since dryRun runs locally, it does not require a token or a build session ID.
Start with the smallest command that matches your build.
At minimum, pass --scanDir for the build output directory and --scmType for the source control type, usually git or none.
In most cases, add --verbose so the console output is easier to read. Use --instrumentForBrowsers for front-end browser builds. Add --hasNycReport and --report only when unit test coverage is part of the integration.
If unit tests are in scope, validate the NYC JSON coverage file in the same run:
A successful run gives you the number of scanned methods, branches, and files, a summary table with validation results, and an sl-dry-run-output folder with the detailed analysis files.
After the command completes, use the summary table to find the first issue to fix.
Example output:
All details, including warnings, errors, and logs, are written to sl-dry-run-output.
If the agent detects a misconfiguration, check the Message column first.
Recommended workflow
Start with the smallest real build output you can validate.
That makes the first troubleshooting pass easier to understand.
Review generated files and fix the main issues
Open the files under sl-dry-run-output to confirm what the agent actually scanned.
Start with included-files.json and excluded-files.json. These two files tell you whether the right files are in scope and whether the current exclusions are working as expected.
Next, review sl-mapping.json to see how source maps resolve back to source files. Use agent-events.json when you need the full warning or error details behind the summary table.
By this point, you can usually tell whether the next fix is about scan scope, source maps, or path alignment.
Fix scan scope first
Exclude files that your developers do not maintain first.
This reduces scan time and improves coverage quality. It also makes the rest of the validation easier to interpret.
If included-files.json contains bundled framework files, vendor assets, or generated output that should not be part of the project scope, update .slignore or .slignore.generated and run dryRun again.
For ignore rule examples, see Ignoring Files or Folders.
Fix source maps next
For front-end builds, open sl-mapping.json and confirm that each mapped source points to a real file in your repository.
If the paths are wrong, review your build's source map configuration before you continue with other fixes. When source maps are wrong, method names, path alignment, and coverage mapping often become noisy at the same time.
See Javascript & Node.js Source Map Files for source map requirements and examples.
Share the output folder with support when you hit a blocker
If the output still does not make the next fix clear, package the entire sl-dry-run-output folder and share it with support.
Attach the ZIP file to a support portal ticket through Contact Support. If you already have an active support email thread, attach the same ZIP there.
Include a short note with the command you ran, the main warning or error, and whether the issue is about scan scope, source maps, or NYC validation.
Map each summary item to the next fix
If several rows fail, fix scope and source map issues first. Those two issues often make the rest of the output look noisier than it really is.
Once you know which row failed, use the table below to choose the most likely next fix.
This mapping helps you move from the command output to the right remediation step without guessing.
Column information
Your source maps do not include column information.
Regenerate source maps with both line and column mapping enabled.
Git Paths
The scanned project structure does not match the Git project structure.
Check --buildScanProjectRoot and make sure it aligns with your repository root.
Raw Third Parties
The scan includes bundled framework or vendor files.
Refine your scan scope and add exclusions in .slignore.
Logical Third Parties
Your source maps resolve to generated or third-party source files.
Fix source map generation and exclude irrelevant mapped files in .slignore.generated.
Nyc Paths
The NYC report paths or signatures do not match the SeaLights build scan.
Validate --buildScanProjectRoot and --nycProjectRoot.
Position Match
Method and branch positions in the NYC report differ too much from the SeaLights scan.
Make sure both analyses use the same code baseline and build configuration.
Common errors
Use these quick answers when you hit a common issue. Expand an item when you need the next step.
JavaScript heap out of memory
Usually means the process needs more memory or the scan scope is too broad.
First, confirm that the scan only includes files your team maintains. Large bundled files, generated assets, and third-party code can increase memory use quickly.
Then review JavaScript heap out of memory troubleshooting for the recommended fixes.
Column information warnings
Usually mean the source maps do not include column mapping
SeaLights needs both line and column information to map methods accurately.
If the warning appears, regenerate the source maps with full column mapping enabled and rerun dryRun.
See JavaScript & Node.js Source Map Files for the expected source map requirements.
Failure during instrumentation
Usually means the parser settings do not match the build
Check whether the build uses ES modules, JSX, or both. For ES modules, add --es6Modules. For React applications, add --babylonPlugins jsx.
If the error continues, review the parser-related options in Command Reference — Running a local validation (dryRun).
Raw Third Parties or Logical Third Parties warnings
Usually mean the scan scope or source maps are too broad
Start by checking whether bundled framework files or vendor files appear in included-files.json.
If they do, tighten .slignore or .slignore.generated. If the warning comes from mapped source files, review sl-mapping.json and fix the source map configuration.
For ignore rule examples, see Ignoring Files or Folders.
Command options reference
For dryRun flags and equivalent command mappings, see Command Reference — Running a local validation (dryRun).
Last updated
Was this helpful?