Effect tsgo Oxlint Pack Research

Scope

Research the 2026-08-04 announcement that Effect language-service diagnostics are available as custom type-aware Oxlint rules, then identify the smallest correct Harness Effect-pack integration.

Primary-source facts

• Mattia Manzati announced that the Effect LSP rules are available as custom, type-aware Oxlint rules and linked the Effect-TS/tsgo setup. Announcement
• The latest published release is @effect/tsgo@0.36.5, from commit cf4147a. Current main contains unreleased changes, so the published release is the implementation authority.
• Upstream requires @effect/tsgo, oxlint, and oxlint-tsgolint. For @effect/tsgo@0.36.5, the compatible direct-install tuple is oxlint@1.78.0 and oxlint-tsgolint@7.0.2001. The patch command rejects unsupported installed versions. Setup, supported versions, compatibility requirement
• Oxlint integration patches installed binaries and must run again after dependency installation. For a lint-only pack, the precise command is effect-tsgo patch --no-typescript --oxlint; the shorter upstream example also patches TypeScript and therefore requires a supported native TypeScript 7 installation. Setup, integration flags
• The supported TypeScript config imports recommended from @effect/tsgo/oxlint-presets and extends it. The preset enables options.typeAware, registers effecttsgo, and owns the curated severities. All Effect rules need type-aware mode. Config, recommended preset, limitation
• The integration remains marked experimental and its packaged binaries support x64/arm64 macOS, Windows, and glibc Linux, but not musl Linux. Flag status, platform discovery

Harness findings

• The Effect pack currently selects only effect-no-barrel-imports in apps/cli/src/data/catalog/packs.ts. That asset is still required because the upstream recommended preset does not replace effect-js/no-import-from-barrel-package.
• Lint config generation already composes Ultracite imports, local rules, JS plugins, dependencies, and nearest-workspace oxlint.config.ts files. It does not model external preset imports, dependency version constraints, or required package scripts.
• Missing lint dependencies currently default to latest. On 2026-08-19, oxlint@latest is 1.79.0, which is outside @effect/tsgo@0.36.5's supported set. Adding package names without exact versions would produce a setup whose prepare step fails.
• Clean macOS arm64 probes confirmed both sides of the compatibility boundary. With oxlint@1.79.0, effect-tsgo patch --no-typescript --oxlint exits with UnsupportedTargetPackageVersionError, listing only 1.77.0 and 1.78.0; running the imported recommended preset without the patch exits with Unknown plugin: 'effecttsgo'. With oxlint@1.78.0, the patch succeeds and Oxlint reports a real effecttsgo(floating-effect) error. Current upstream main still packages only the 1.77/1.78 Oxlint components.
• Existing package scripts and dependency protocols are project-owned state. Integration must compose and deduplicate the Effect patch command, preserve unrelated script content, preserve compatible existing versions, and fail closed rather than silently replace incompatible or non-semver dependency protocols.

Synthesized implementation direction

1. Keep the existing barrel-import asset and add a separate Effect tsgo recommended asset.
2. Extend the CLI-owned lint-asset model with external named preset imports, exact required dependency versions, and required package scripts. Keep these generic lint capabilities; do not special-case Effect inside the config encoder.
3. Import the published upstream recommended preset rather than copying its rule list.
4. Generate the exact compatible dependency tuple and compose effect-tsgo patch --no-typescript --oxlint into prepare without overwriting existing commands or duplicating the patch on repeated scaffold runs.
5. Test through the built CLI scaffold seam: an Effect repository receives both assets, the imported preset, the existing barrel rule, the compatible dependency tuple, and the composed prepare command. Also exercise a real type-aware Effect diagnostic when the host platform supports the patched integration.
6. Document that the integration is experimental, version-coupled, and unavailable on musl Linux.

Conflicts and uncertainty

• Upstream documentation commonly shows floating installs, but the same documentation requires installed versions to match the release's supported set. Harness must prefer the explicit compatibility table because its scaffold is expected to remain installable after publication.
• Whether a repository with an incompatible pre-existing Oxlint dependency should be upgraded automatically is a product-policy decision. Current Harness preservation rules argue for a clear validation failure with remediation rather than silent replacement.
• Projects that also enable Effect LSP diagnostics may see duplicate findings. Upstream recommends setting language-service diagnostics to false, but this lint-pack change should document that choice rather than mutate tsconfig.json outside the lint asset's ownership.