JavaScript/TypeScript linting: nothing covers astro.config.mjs or src/ TypeScript
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 52/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- eslint, github-actions, javascript, typescript
Línea de trabajo
Empieza leyendo .mega-linter.yml y .github/workflows/mega-linter.yml, y luego compara la ejecución existente de MegaLinter enlazada en el issue. Elige y documenta el enfoque de linting y el comportamiento de APPLY_FIXES, verifica que astro.config.mjs aparezca en el resumen de lint de JS/TS e introduce un error de lint temporal para confirmar que el job falla.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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 withtypescript-eslintandeslint-plugin-astro. This activatesJAVASCRIPT_ESandTYPESCRIPT_ESin MegaLinter automatically — no.mega-linter.ymlchange needed — andeslint-plugin-astrogives.astrofiles genuine coverage rather than the best-effort HTML treatment the config currently assumes. Most work, most value. - Or set
JAVASCRIPT_DEFAULT_STYLE: prettierandTYPESCRIPT_DEFAULT_STYLE: prettierin.mega-linter.yml. Cheap, but it only catches formatting, not correctness. NoteJSON_PRETTIERandYAML_PRETTIERare already inDISABLE_LINTERSfor conflicting with the linters that own those formats, so this would want checking againststylelint/editorconfig-checkerfor 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.mjsis 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_FIXESsettings reflect it - Introducing a lint error in
astro.config.mjsfails the MegaLinter job
- Lenguaje dominante
- HTML
- Estrellas
- 0
- Forks
- 0
- Merge medio
- 8 h 17 min
- PR fusionados (30 d)
- 58
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de laywill/laywill.github.io
-
design
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
laywill/laywill.github.io#186 ·
-
design
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
laywill/laywill.github.io#183 · 1 comentario ·
-
Dificultad 2/5 Medio día Aptitud para principiantes 74/100
laywill/laywill.github.io#135 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
laywill/laywill.github.io#106 ·
-
infra needs-william
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
laywill/laywill.github.io#35 · 1 comentario ·
Todos los issues de laywill/laywill.github.io
Issues similares
-
Solved site promotion gate fails on runner PHP patch drift (expects 8.2.33, runner installs 8.2.34) Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Automattic/blocks-engine#2161 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 60/100
github/gh-aw-mcpg#13748 ·
-
agentic-workflows
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
personalrobotics/tsr#128 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Azure/azure-functions-docker#1257 ·