JavaScript tests are found only by file name (*.test.*, *.spec.*, __tests__/): the classic test/ directory with mocha, node --test, node:assert is "no tests"; jest via node ./node_modules/jest/bin/jest.js, borp, xo, nub are unknown runners
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- javascript, node.js, python
Línea de trabajo
The JavaScript test and runner detection lives in ecosystems/javascript/init.py: the file-name regex near line 309, the _JS_RUNNERS set near line 311, and the _js_tests logic around lines 314-323. Start by reproducing one case from the issue, such as a test/index.js run by npm test, and check which branch rejects it. Done means the listed repros (mocha in test/, a node <path>/jest/bin/jest.js script, and borp) pass with fixtures and the existing tests still pass.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
express, got, mime-db (whose nyc coverage PASSes in the same run), octokit/graphql-schema: a test/ directory run by npm test → FAIL "no tests found". phoenix and actions/checkout run node --experimental-vm-modules ./node_modules/jest/bin/jest.js (Jest's documented ESM invocation) → "no CI runs jest … (or npm test)" although npm test was read. fastify runs borp (a node:test runner wrapping c8, with --check-coverage --lines 100), got runs xo (eslint wrapper, thousands of packages), zod runs everything through nub run <script>. ecosystems/javascript/__init__.py:309 should also take test/**/*.{js,ts} (and tests/) when a known runner or npm test runs, and match runners by the script they execute. Also: got's tsconfig extends a strict base, so the "enable strict" hint is wrong.
Evidence from the corpus audit
phoenixframework/phoenix / tests-run
- kind: FALSE_NEGATIVE (MESSAGE)
- actual: FAIL "JavaScript/TypeScript: tests found in 6 file(s), but no CI configuration runs jest, vitest, mocha,
node --test, deno test, bun test or playwright (or npm test)" - expected: PASS for JavaScript: CI runs
npm test, whose script runs Jest. - evidence:
.github/workflows/ci.yml:151:run: npm test;package.json:35:"test": "node --experimental-vm-modules ./node_modules/jest/bin/jest.js";jest.config.js:21:testRegex: "/assets/test/.*_test\\.js$". The facts show the
script was expanded (Command origin package.json:scripts.test argv ["node","--experimental-vm-modules", "./node_modules/jest/bin/jest.js"]), butproject_validator/ecosystems/javascript/__init__.py:314-323only
acceptsprogram(argv) in {"jest","vitest","mocha","ava"}ornode --test; a runner launched as
node <path>/jest/bin/jest.js(the documented way to run Jest with ESM) is not recognised. The message's
"(or npm test)" is also misleading:npm testwas run and read. - repro:
package.json{"scripts":{"test":"node --experimental-vm-modules ./node_modules/jest/bin/jest.js"}},
a.test.js, workflowrun: npm test - confidence: high
jshttp/mime-db / tests-run
- kind: FALSE_NEGATIVE
- actual: FAIL: no tests found (.test., .spec. or tests/ files)
- expected: PASS: the mocha convention
test/*.jsrun bynpm teston 29 Node versions. The same run also credits
nyc for coverage (PASS "branch coverage is reported with nyc"), which wrapsnpm test; a project with measured
coverage and "no tests" is self-contradictory. - evidence:
test/index.js:1-4:var assert = require('assert')...;package.json:
"test": "mocha --reporter spec --check-leaks test/","test-ci": "nyc --reporter=lcovonly --reporter=text npm test";
.github/workflows/ci.yml"Run tests" step:npm run test-ci/npm test; validator
project_validator/ecosystems/javascript/__init__.py:309:path=re.compile(r"(?:^|/)(?:[^/]*(?:[._]test|\.spec)\.[^/]+|__tests__/.+)$"). - repro:
test/index.jswithdescribe(/it(+"test": "mocha test/"+ a steprun: npm test. - confidence: high
actions/checkout / tests-run
- kind: FALSE_NEGATIVE
- actual: FAIL "JavaScript/TypeScript: tests found in 10 file(s), but no CI configuration runs jest, vitest, mocha,
node --test, deno test, bun test or playwright (or npm test)". - expected: PASS: CI runs
npm test, whose script is Jest's documented ESM invocation. - evidence:
.github/workflows/test.yml:27:- run: npm test;package.json:12:"test": "node --experimental-vm-modules node_modules/jest/bin/jest.js". Validator:ecosystems/javascript/__init__.py:314-321:
_js_testsacceptsname in _JS_RUNNERSor(name == "node" and "--test" in argv);node <path>/jest.jsmatches
neither, andnpm testitself (named in the hint) is not credited when its script is unrecognised. - repro:
package.json"test": "node --experimental-vm-modules node_modules/jest/bin/jest.js",src/a.test.ts,
workflowrun: npm test. - confidence: high
octokit/graphql-schema / tests-run
- kind: FALSE_NEGATIVE
- actual: FAIL:
no tests found (*.test.*, *.spec.* or __tests__/ files) - expected: PASS: a
test/directory of node:assert tests runs on every push vianpm test. - evidence:
package.json:13:"test": "node test",;test/index.js:1-2:import "./smoke.js";/import "./validate.js";;test/smoke.js:1-5:import { strict } from "assert";...strict.equal(typeof validate, "function");;.github/workflows/test.yml:20:- run: npm test - evidence (validator): ecosystems/javascript/init.py:307-309:
name="*.test.*, *.spec.* or __tests__/ files"/path=re.compile(r"(?:^|/)(?:[^/]*(?:[._]test|\.spec)\.[^/]+|__tests__/.+)$"): a top-leveltest/directory (mocha's and node's classic layout) is not a test location.npm testitself is accepted as a runner, so only the file pattern is missing. - repro:
package.jsonwith"test": "node test",test/index.js, workflowrun: npm test. - confidence: high
expressjs/express, sindresorhus/got / tests-run
- kind: FALSE_NEGATIVE
- actual: FAIL:
no tests found (*.test.*, *.spec.* or __tests__/ files)(both projects) - expected: PASS: both have a
test/directory of test files that CI runs through a known runner. - evidence:
- express
package.json:94:"test": "mocha --require test/support/env --reporter spec --check-leaks test/ test/acceptance/";
package.json:95:"test-ci": "nyc --exclude examples --exclude test --exclude benchmarks --reporter=lcovonly --reporter=text npm test";
.github/workflows/ci.yml:80:run: npm run test-ci;test/holds 74 files (test/app.js,test/Router.js, ...) - got
package.json:"test": "xo && tsc --noEmit && NODE_OPTIONS='--import=tsx/esm' node --test --test-timeout=60000 'test/*.ts'";
.github/workflows/main.yml:26:- run: npm run test;test/holds 43.tsfiles (test/abort.ts,test/http.ts, ...) - validator:
project_validator/ecosystems/javascript/__init__.py:309:
path=re.compile(r"(?:^|/)(?:[^/]*(?:[._]test|\.spec)\.[^/]+|__tests__/.+)$")— nothing undertest/ortests/
counts unless the file name itself says test.facts/roles.py:27already mapstest,tests,specdirectories to
thetestrole; the tests-run question does not use it. Note express'scoveragecheck PASSes "branch coverage is
reported with nyc" in the same run: the validator followednpm testto mocha for coverage but reports no tests (MESSAGE).
- express
- repro:
package.json{"scripts":{"test":"mocha test/"}},test/app.jswith onedescribe, workflow steprun: npm test. - confidence: high
fastify/fastify / tests-run, coverage
- kind: UNSUPPORTED
- actual: FAIL:
tests found in 198 file(s), but no CI configuration runs jest, vitest, mocha, node --test, deno test, bun test or playwright (or npm test); coverage FAILno branch coverage measurement found - expected: PASS: CI runs
npm run unit->borp(a node:test runner wrapping c8) andnpm run coverage:ci-check-coverage->borp --coverage --check-coverage --lines 100. - evidence:
package.json:29:"unit": "borp";package.json:16:"coverage:ci-check-coverage": "borp --reporter=@jsumners/line-reporter --coverage --check-coverage --lines 100";
.github/workflows/ci.yml:85-87:- name: Run tests/run: |/npm run unit;.github/workflows/coverage-nix.yml(called fromci.yml:45):run: |/npm run coverage:ci-check-coverage;
.borp.yaml:1-3:files:/- 'test/**/*.test.js'. Validatorecosystems/javascript/__init__.py:311:_JS_RUNNERS = frozenset({"jest", "vitest", "mocha", "ava"}).
borp is used across the fastify organisation (andtap/node-tapis similarly absent).test:types->tstyche(type tests) is also unknown totype-checking. - repro:
package.json{"scripts":{"unit":"borp"}}+.borp.yaml+ steprun: npm run unit. - confidence: high (as a gap)
sindresorhus/got / static-analysis, compiler-warnings, warnings-as-errors
- kind: UNSUPPORTED
- actual: FAIL:
no static analyzer runs; FAILno JavaScript linters found; enable at least eslint - expected: PASS:
xo(the eslint wrapper used by every sindresorhus package and thousands of others) runs in CI throughnpm run test, configured in package.json'sxokey. - evidence:
package.json:"test": "xo && tsc --noEmit && ...","xo": [ { "ignores": [...] }, { "rules": { "@typescript-eslint/no-empty-function": "off", ... } } ];
.github/workflows/main.yml:26:- run: npm run test. - repro:
package.json{"scripts":{"test":"xo"},"xo":{}}+ steprun: npm test. - confidence: high (as a gap)
colinhacks/zod / tests-run, static-analysis, code-formatting
- kind: UNSUPPORTED, MESSAGE
- actual: FAIL:
tests found in 203 file(s), but no CI configuration runs jest, vitest, ...; FAILbiome is configured (biome.jsonc, ...) but does not run; WARNbiome.jsonc ... is defined but CI does not run ... biome - expected: PASS for all three: CI runs the package scripts through the
nubrunner:nub run test->vitest run,nub run lint:check->biome lint .,nub run format:check->biome check ..
Also: the strict and--allow-unknownoutputs are identical (diffSAME), i.e. an unknown programnubproduced a confident FAIL, not an "unknown". - evidence:
.github/workflows/test.yml:28:uses: nubjs/setup-nub@47e5e7393d50f4e9544ddaf756aa277972afba2d # v0;test.yml:37:- run: nub run test;
test.yml:52-53:- run: nub run format:check/- run: nub run lint:check;package.json:78:"test": "nub exec --node vitest run";
package.json:72:"format:check": "nub exec --node biome check .";package.json:74:"lint:check": "nub exec --node biome lint .".
Validatorecosystems/javascript/__init__.py:87-110knows npm/pnpm/yarn/bun/deno only. nub is new and rare, so this is a gap, but
<unknown> run <script>where<script>is a package script could be treated as a script runner, or at least as unread. - repro: step
run: nub run testwithpackage.json{"scripts":{"test":"vitest run"}}. - confidence: medium
sindresorhus/got / type-checking (strict hint)
- kind: MESSAGE
- actual: PASS:
tsc (tsconfig.json) runs+ hintconsider enabling strict mode: "strict": true in the compilerOptions of tsconfig.json - expected: the hint should allow for an
extendsbase: got's tsconfig extends@sindresorhus/tsconfig, which is strict. - evidence:
tsconfig.json:2:"extends": "@sindresorhus/tsconfig",. The base lives in node_modules, so it cannot be read; saying "strict is not visible (extends @sindresorhus/tsconfig)" would be accurate. - repro:
tsconfig.json{"extends":"@tsconfig/strictest"}(the docs say@tsconfig/strictestis recognised, so a named-base allowlist exists and could grow). - confidence: low
Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.
🤖 Generated with Claude Code
- Lenguaje dominante
- Python
- Estrellas
- 4
- Forks
- 1
- Merge medio
- 10 h 41 min
- PR fusionados (30 d)
- 79
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
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 cpp-best-practices/project_validator
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
cpp-best-practices/project_validator#267 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
cpp-best-practices/project_validator#263 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
cpp-best-practices/project_validator#260 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
cpp-best-practices/project_validator#259 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
cpp-best-practices/project_validator#255 ·
Los mantenedores suelen responder en 1 día
Todos los issues de cpp-best-practices/project_validator
Issues similares
-
plot_graph crashes when a mesh node has no m2m edgePosiblemente ocupada @tygvi la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
mllam/neural-lam#883 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
enhancement possible-duplicate
Dificultad 1/5 1-3 horas Aptitud para principiantes 78/100
AOSSIE-Org/PictoPy#1715 · 2 comentarios ·
Los mantenedores suelen responder en 6 días
-
SQLite connector omits generated columns from the catalog, and drops relationships sourced on themAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
NVIDIA/auto-ontology#511 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ethereum/execution-specs#3996 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Project-N-E-K-O/N.E.K.O#3725 ·
Los mantenedores suelen responder en 1 día