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
Mantenedores costumam responder em até 1 dia
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 35/100
- Tipo de issue
- Bug
- Clareza
- Razoavelmente clara
- Status de atividade
- Ativa
- Stack de tecnologia
- javascript, node.js, python
Direção de pesquisa
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.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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
- Linguagem predominante
- Python
- Estrelas
- 4
- Forks
- 1
- Merge médio
- 10h 41min
- PRs com merge (30d)
- 79
Preparar o ambiente
Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de cpp-best-practices/project_validator
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 62/100
cpp-best-practices/project_validator#267 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
cpp-best-practices/project_validator#263 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 62/100
cpp-best-practices/project_validator#260 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
cpp-best-practices/project_validator#259 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
cpp-best-practices/project_validator#255 ·
Mantenedores costumam responder em até 1 dia
Todas as issues de cpp-best-practices/project_validator
Issues semelhantes
-
documentation type/bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
add entry to blockAberta
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 65/100
StevenBlack/hosts#3299 ·
-
`garak --report` overwrites the input report when its name has no ".report"Talvez já em andamento @0z5a assumiu hoje. Abertaneeds-triage
Dificuldade 2/5 Meio dia Facilidade para iniciantes 72/100
Mantenedores costumam responder em até 2 dias
-
trace: Pi's 1-hour cache writes are priced at 1.25x, but billed at 2xTalvez já em andamento @Shizoqua assumiu hoje. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
microsoft/TokenEconomizer#221 ·
Mantenedores costumam responder em até 1 dia
-
plot_graph crashes when a mesh node has no m2m edgeTalvez já em andamento @tygvi assumiu hoje. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
mllam/neural-lam#883 · 1 comentário ·
Mantenedores costumam responder em até 2 dias