.deepsource.toml

version = 1

# `pkg/` is deliberately NOT excluded from DeepSource analysis.
# It holds hand-written module loaders (e.g. the Pyodide shim et_ws_pydata1.js) alongside build output. The int-gen
# outputs under `generated/` and the scenario `verification/` fixtures are excluded because they are fully generated;
# if genuinely-generated glue under `pkg/` turns up as a finding, add a narrow per-file exclude then.
# The runner's `src/bindings.rs` is the one int-gen output that cannot sit under `generated/`, so it is excluded
# by path; refer to int-gen bindings.rs for details.
# `**/error.rs` is excluded outright: these files are thin error-type plumbing (thiserror `#[derive]` + `#[from]`
# conversions, plus the occasional unreachable defensive `From`), so their line coverage is noise. The exclude also
# suppresses issue detection there, because the Rust analyzer runs -- it is enabled in the DeepSource dashboard
# rather than in this file. (The matching Codecov exclusion is set in Codecov's web UI.)
exclude_patterns = ["**/error.rs", "**/ws-wasi-runner/src/bindings.rs", "generated/**", "verification/**"]

# Repo convention: tests live in a `tests/` directory or in source files prefixed `test_`.
test_patterns = ["**/test_*.py", "**/tests/**"]

# Dart is explicitly deactivated; its coverage comes from the mise pipeline's check:dart instead.
# DeepSource's Dart support is an AI-only analyzer (no classic static analysis), so with AI review off it
# auto-surfaces as a perpetually-skipped "DeepSource: Dart" check on every PR.
[[analyzers]]
enabled = false
name = "dart"

[[analyzers]]
enabled = true
name = "python"

# The browser modules and the ws-server `static/app.js` are ES modules (top-level `import`/`export`).
# Without an es-modules parser the analyzer treats them as scripts and reports spurious JS-0833 errors
# ("'import'/'export' may appear only with 'sourceType: module'"), which it still does despite this setting.
#
# Ruled out, so nobody spends a fourth attempt on it: the settings reaching the analyzer at all.
# These were `[analyzers.meta]` table headers, three of them in this file, each binding to the last
# `[[analyzers]]` declared above it -- a shape a lenient parser could flatten so that only the final one
# survives, which would leave javascript with no module_system and explain the errors exactly. Rewriting all
# three as inline `meta` keys, which cannot be reattached or overwritten, changed nothing: run
# 4e3986bd-db2f-440a-84fc-9163ef240292 on commit
# https://github.com/edge-toolkit/core/commit/ab14bf545bf62125dfa4f314952f5cd2b5a6be61 still failed.
# The inline form is kept only because it is unambiguous; it is not the fix.
#
# Also ruled out: the files themselves. The repo's own JS linter parses every one of them as an ES module
# with no parse error, and `module_system` is a documented key whose value here is one of its documented
# options -- so neither the source nor the spelling of this setting is what the analyzer is objecting to.
#
# Ruled out last, and the reason no spelling of the key below can ever be the fix: `es-modules` is the
# analyzer's own DOCUMENTED DEFAULT for `module_system`, so writing it out restates what was already in force
# and changes nothing by construction. The package boundary a parser would otherwise resolve a bare `.js`
# against says the same thing -- every module's `pkg/package.json` already carries `"type": "module"`. Both
# inputs declare an ES module, JS-0833 is reported regardless, and the finding is reported only for files a
# given diff touches, so it arrives two or three at a time rather than all at once. What remains is a per-file
# `// skipcq: JS-0833` above the first export, added as each shim next comes up in a review.
[[analyzers]]
enabled = true
meta = { environment = ["browser", "nodejs"], module_system = "es-modules" }
name = "javascript"

[[analyzers]]
enabled = true
name = "csharp"

[[analyzers]]
enabled = true
name = "docker"

[[analyzers]]
enabled = true
name = "cxx"

# runtime_version is required, and its range stops at 21 while config.java.toml pins JDK 26.
# DeepSource reports incorrect results when the value is unset or mismatched, so it tracks the newest runtime the
# analyzer offers rather than the one java-data1 actually compiles against.
[[analyzers]]
enabled = true
meta = { runtime_version = "21" }
name = "java"

# language_version stops at 2.1 while kotlin-data1's Gradle build pins Kotlin 2.4.10.
# The module's source stays within the 2.1 dialect, so the older parser still reads it; a future file that reaches
# for newer syntax would fail to parse instead. runtime_version is left at its default because a wasmJs-only
# multiplatform target has no JVM runtime for the JVM-API rules to judge.
[[analyzers]]
enabled = true
meta = { language_version = "2.1" }
name = "kotlin"