Sample Monorepo ZIP — Multi-Language Companion
Tiny multi-language SAMPLE monorepo ZIP (web/api/util/scripts) for unpack-then-lint and monorepo tooling.
- README.md
- hello.js
- hello.py
- hello.go
- lint.sh
Specifications
- Members
- 5
- Languages
- js,py,go,sh
- Wave
- G
Testing contract
Expected to pass- Scenario
- Unpack the archive and run a language-aware linter over the resulting tree.
- Expected result
- Five members extract into a three-directory monorepo layout: README.md, apps/web/hello.js, apps/api/hello.py, packages/util/hello.go and scripts/lint.sh. Four languages are present across three top-level directories, so a tool that infers project type from the repository root finds no single answer - which is the case this fixture exists for. Every member is DEFLATE-compressed, and paths use forward slashes, so an extractor must not flatten the directory structure.
What is a .zip file?
ZIP is a widely supported archive format that bundles multiple files and directories into one container, typically with per-file DEFLATE compression and a central directory index. It supports random access to individual entries without decompressing the whole archive. It underlies many document formats such as DOCX and EPUB.
How to use this file
Use an example ZIP to test archive extraction, central-directory parsing, per-entry decompression, and protection against path-traversal (zip-slip) during unpacking.
How to use this file for testing
“Sample Monorepo ZIP — Multi-Language Companion” is a deterministic Novus Examples fixture for Code parsing, Conversion testing. Short, known-correct source files in many languages with classes, functions, generics, enums, and error handling, for testing parsers, linters, formatters, language detection, and diff viewers.
Documented properties for this file: ZIP · 796 bytes. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such, expect parsers to fail loudly rather than silently accept them.
This is a short, known-correct source file. Run it through your syntax highlighter, linter, formatter, tree-sitter grammar, or parser, and open it in the in-browser editor to tweak and re-download. Each snippet exercises comments, string escapes, literals, and language keywords.
Code examples
unzip -l sample-monorepo.zip # list members
unzip sample-monorepo.zip -d out/ # extractRelated files
- xmlCoverage — Clover XMLThe Clover serialisation, whose <metrics> element rolls statements, conditionals and methods into a single elements/coveredelements pair. Anything reading only that pair reports a blended percentage that matches none of the other three formats unless the components are separated first. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

- xmlCoverage — Cobertura at Zero CoverageA structurally complete Cobertura report in which line-rate and branch-rate are 0.0 everywhere. The counterpart to the zero-coverage LCOV file, for checking that a converter keeps the class and method structure when there is nothing covered to describe.

- xmlCoverage — Cobertura Condition-Coverage AttributesCobertura with a condition-coverage attribute on every branching line, written in the "50% (1/2)" form. The percentage and the fraction can disagree in real reports, so a parser should read the fraction and treat the percentage as derived.

- xmlCoverage — Cobertura with One Package per DirectoryThe same coverage split into one package per source directory with dotted names, the layout a JVM project produces. Reports that key on class name alone collide as soon as two packages hold a class of the same name, which this file is shaped to expose.

- xmlCoverage — Cobertura with Several Source RootsThree <source> roots with class filenames given relative to them, which is how Cobertura represents a multi-root project. A viewer must try each root in turn to resolve a file; one that assumes a single root shows "source not found" for most of the report.

- xmlCoverage — Cobertura XMLThe Cobertura serialisation of the same run, with packages, classes, per-method line rates and condition-coverage attributes on every branching line. Cobertura expresses coverage as rates rather than counts, so this is the file that catches converters rounding a percentage into a hit count. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

Generated by generation/code_wave_g.py. Free for any use, no attribution required, license.