Skip to content

Add ESLint configuration and fix linting issues across monorepo packages #339

Description

@Lakes41

Background

The current build pipeline includes a pnpm lint command, but the monorepo lacks a unified ESLint configuration. Without centralized linting rules, code quality, import consistency, and style diverge across packages. This is especially critical during the Stellar/Soroban migration where new patterns (SEP-10, Soroban contracts) need to follow consistent standards.

Problem

  1. No shared ESLint config: Each package may have its own or no .eslintrc at all
  2. Inconsistent import rules: Hardcoded .js imports (see related issue) suggest linting doesn't enforce best practices
  3. No type-aware linting: TypeScript strict mode and type safety aren't enforced via ESLint
  4. Maintenance burden: Linting rules are not documented or synced across packages

Expected Outcome

  • Single, shared .eslintrc.json or eslint.config.js in the workspace root
  • All packages inherit and extend consistent rules
  • Linting enforces import practices, type safety, and code style
  • CI can fail on lint violations
  • Developers get immediate feedback during editing (via IDE integration)

Suggested Implementation

  1. Create a shared ESLint config in the workspace root:

    pnpm install -D eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser eslint-plugin-import
  2. Create .eslintrc.json in the workspace root:

    {
      "root": true,
      "parser": "@typescript-eslint/parser",
      "parserOptions": {
        "ecmaVersion": 2020,
        "sourceType": "module",
        "project": "./tsconfig.json"
      },
      "plugins": [
        "@typescript-eslint",
        "import"
      ],
      "extends": [
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended",
        "plugin:import/errors",
        "plugin:import/warnings",
        "plugin:import/typescript"
      ],
      "rules": {
        "@typescript-eslint/explicit-module-boundary-types": "off",
        "@typescript-eslint/no-explicit-any": "warn",
        "import/extensions": [
          "error",
          "ignorePackages",
          {
            "ts": "never",
            "tsx": "never",
            "js": "never",
            "jsx": "never"
          }
        ],
        "import/no-unresolved": "error"
      }
    }
  3. Add .eslintignore to exclude build artifacts, node_modules:

    node_modules/
    dist/
    .next/
    build/
    
  4. Update root package.json lint script:

    "lint": "eslint . --ext .ts,.tsx",
    "lint:fix": "eslint . --ext .ts,.tsx --fix"
  5. For each package, either:

    • Remove local .eslintrc (inherit from root), or
    • Create a minimal packages/*/eslintrc.json that extends the root config
  6. Run linting:

    pnpm lint              # Check
    pnpm lint:fix          # Auto-fix
    pnpm -r lint           # Lint all packages
  7. Integrate into CI/CD (e.g., GitHub Actions) to fail on violations

Acceptance Criteria

  • Workspace root .eslintrc.json defines shared rules
  • All TypeScript/JavaScript files pass linting (or violations are fixed)
  • pnpm lint runs without errors
  • pnpm lint:fix auto-fixes common issues
  • ESLint rules enforce:
    • No hardcoded .js extensions in source imports
    • Type safety best practices
    • Consistent code style
  • IDE extensions (VSCode ESLint) show real-time feedback
  • CI/CD pipeline runs pnpm lint and fails on violations

Affected Files/Directories

  • .eslintrc.json (create at workspace root)
  • .eslintignore (create at workspace root)
  • All packages/*/ and apps/*/ directories (inherit config)
  • package.json (update lint scripts)
  • CI/CD workflows (add linting step)

Metadata

Metadata

Assignees

Labels

Third CampaignOfficial FWC26 campaign issue — eligible for campaign scoring and rewardsadvancedAdvanced difficulty tasks requiring significant domain knowledge and implementation effortconsistencyPattern and convention standardization across the codebase for uniformitytype-safetyTypeScript type system improvements and strict type enforcement

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions