laywill / laywill/laywill.github.io

JavaScript/TypeScript linting: nothing covers astro.config.mjs or src/ TypeScript

Open
#49 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

infra needs-william
Dominant language
HTML
Stars
0
Forks
0
Avg merge
8h 17m
Merged PRs (30d)
58

Description

Found while reviewing #47 (Astro scaffold). That PR adds astro.config.mjs at the repo root and nothing in CI lints or type-checks it. The same hole will apply to src/** TypeScript as soon as there is any.

JAVASCRIPT and TYPESCRIPT are both listed in ENABLE: in .mega-linter.yml, but three activation rules combine so that no JS/TS linter actually runs.

1. JAVASCRIPT_ES / TYPESCRIPT_ES are inactive — there is no ESLint config. From the MegaLinter run on #47 (33994992304):

[Activation] JAVASCRIPT_ES has been set inactive, as none of these files has been found:
['eslint.config.js', 'eslint.config.mjs', 'eslint.config.cjs', 'eslint.config.ts',
 'eslint.config.mts', 'eslint.config.cts', '.eslintrc.json', '.eslintrc.yml',
 '.eslintrc.yaml', '.eslintrc.js', '.eslintrc.cjs', 'package.json:eslintConfig']

An identical line follows for TYPESCRIPT_ES. Confirmed against the tree: no eslint.config.*, no .eslintrc.* and no eslintConfig key in package.json, on either main or the PR branch.

2. JAVASCRIPT_PRETTIER / TYPESCRIPT_PRETTIER are skipped by the default style setting.

Some linters were skipped due to activation rules:
- JAVASCRIPT_PRETTIER: JAVASCRIPT_DEFAULT_STYLE=standard (set JAVASCRIPT_DEFAULT_STYLE=prettier to activate)
- TYPESCRIPT_PRETTIER: TYPESCRIPT_DEFAULT_STYLE=standard (set TYPESCRIPT_DEFAULT_STYLE=prettier to activate)

3. standard never runs either. Neither the MATCHING LINTERS table nor the run summary contains a JAVASCRIPT or TYPESCRIPT row at all. The summary descriptors on that green run are CSS, EDITORCONFIG, JSON, MARKDOWN, REPOSITORY, SPELL and YAML — and nothing else.

Net effect: the only tools that see astro.config.mjs are editorconfig-checker (whitespace, indentation, trailing newline) and cspell (spelling). Nothing parses it as JavaScript.

Options

  • Add an ESLint flat config (eslint.config.mjs), probably with typescript-eslint and eslint-plugin-astro. This activates JAVASCRIPT_ES and TYPESCRIPT_ES in MegaLinter automatically — no .mega-linter.yml change needed — and eslint-plugin-astro gives .astro files genuine coverage rather than the best-effort HTML treatment the config currently assumes. Most work, most value.
  • Or set JAVASCRIPT_DEFAULT_STYLE: prettier and TYPESCRIPT_DEFAULT_STYLE: prettier in .mega-linter.yml. Cheap, but it only catches formatting, not correctness. Note JSON_PRETTIER and YAML_PRETTIER are already in DISABLE_LINTERS for conflicting with the linters that own those formats, so this would want checking against stylelint/editorconfig-checker for the same class of disagreement.
  • Or accept the gap deliberately and record why. Not recommended once src/** has TypeScript in it.

Behavioural change worth being deliberate about

.mega-linter.yml sets APPLY_FIXES: yes and .github/workflows/mega-linter.yml sets APPLY_FIXES_MODE: commit with APPLY_FIXES_EVENT: pull_request. Whichever formatter is turned on will start auto-committing formatting changes onto PR branches via git-auto-commit-action. That is a real change in how the repo behaves on every PR, not just a new check, so it should be a conscious choice rather than a side effect of enabling a linter.

Related, but a separate fix

astro check (wired as npm run check in package.json) is not run by any workflow either. docs/overhaul/architecture.md already lists "Astro build (astro check + astro build)" as a pipeline job, and .mega-linter.yml carries a NOTE that no MegaLinter linter understands Astro component syntax natively — so astro check is the only thing that will ever type-check .astro frontmatter, whatever we decide above. #47 flags wiring npm run build / npm run check into CI as a follow-up. That belongs with #25 (tag-gated release pipeline), whose lint + SAST + build + link check job set is where those steps land; this issue is scoped to the linter configuration only.

Also worth knowing while sizing the ESLint option: FILTER_REGEX_EXCLUDE in .mega-linter.yml ends in \.astro, and being unanchored it matches every *.astro file, not just the .astro/ build cache directory. So src/**/*.astro is currently excluded from MegaLinter entirely and the "best-effort HTML coverage" the config's NOTE assumes is not happening. That is the same unanchored-regex bug as the \.git / .github/ one tracked in #48 and should be fixed there rather than here, but it changes what eslint-plugin-astro would buy us.

Acceptance criteria

  • A decision is recorded (ESLint, Prettier-only, or deliberate no-op) with its rationale
  • astro.config.mjs is analysed by a JS/TS linter on PRs, evidenced by a JAVASCRIPT or TYPESCRIPT row in the MegaLinter summary table
  • A deliberate call is made on whether the enabled formatter may auto-commit to PR branches, and APPLY_FIXES settings reflect it
  • Introducing a lint error in astro.config.mjs fails the MegaLinter job

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading .mega-linter.yml and .github/workflows/mega-linter.yml, then compare the existing MegaLinter run linked in the issue. Choose and document the linting approach and APPLY_FIXES behavior, verify that astro.config.mjs appears in the JS/TS lint summary, and introduce a temporary lint error to confirm the job fails.

Written by the indexing model from the issue text.

Assessment

Tech stack
eslint, github-actions, javascript, typescript
Domain
ci-cd, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.