Find files, editable templates and browser test targets by what you need to make or test. Explore complete business kits for connected records, templates and expected results.
Page 195 of 221; 24 results per page.
The classic hello-world in TypeScript (shipped as .mts to avoid the MPEG-TS .ts collision): a typed function for testing TypeScript-aware highlighters and the tsc compiler.
A realistic TypeScript snippet with an enum, a discriminated union, generics, exhaustive switch handling, and a typed reduce, for testing the type checker, highlighters, and the TS ESLint parser.
A single stroke-style UI icon (a document) as a 24×24 SVG: the kind of vector icon used in interfaces, for testing icon rendering, recolouring, and SVG-to-PNG conversion.
A reference sheet in which each of the ten shipped bidi control characters appears literally between ASCII guards, with its code point, UTF-8 bytes and the job it does. The two override characters are named but deliberately absent: a bidi rendering fixture does not need to ship the Trojan Source vector.
A fictional multilingual contact for checking Unicode decoding and round trips between legacy and current vCard versions. This member uses vCard 2.1 syntax.
A fictional multilingual contact for checking Unicode decoding and round trips between legacy and current vCard versions. This member uses vCard 3.0 syntax.
A fictional multilingual contact for checking Unicode decoding and round trips between legacy and current vCard versions. This member uses vCard 4.0 syntax.
Control names and labels outside ASCII, including a combining-accent pair that is visually identical to a precomposed one. A form parser that normalises names, or that assumes ASCII, produces a different key set from one that does not.
A one-line file changed in place. Both ranges have length one, so the header is written `@@ -1 +1 @@` with no comma and no count: the abbreviation the unified format allows and that regexes of the form `-(\d+),(\d+)` fail to match.
Byte-for-byte the same diff as its LF twin except that every line ends CR LF, which is what a diff produced or saved on Windows looks like. Readers that compare a hunk line against expected content without stripping the CR find that no line matches.
The mirror of the added-file fixture: every line is a deletion and the new range is `+0,0`. A renderer that writes an empty file instead of unlinking it, or that reports the change as a truncation, fails this one.
Quilt, Debian and vendor trees check patches into the repository, so editing one produces a diff whose body is itself full of `+++`, `---` and `@@` lines and whose section heading is a `diff --git` line. Any scanner that finds file boundaries by searching for those tokens anywhere in the stream splits this single-file diff into several phantom files.
git appends the enclosing declaration after the closing `@@` of each hunk header. The text is free-form and is not part of the range, so a parser that splits the header on `@@` and takes the last field reads the function signature as a range.
The LF half of the line-ending twin pair: identical text content to the CRLF fixture, differing only in the terminator bytes. Diff the two downloads to see nothing but line-ending changes, and use the pair to score end-of-line normalisation.
The file itself is LF-terminated, but every removed line carries a literal CR as its last character because the change under review is a CRLF-to-LF conversion. Renderers that do not show the CR display a hunk in which every removed and added line looks identical.
A file created from nothing: the old side is `/dev/null` and the hunk header carries the zero-length range `-0,0`. Parsers that compute a 1-based start line from the old range produce line 1 instead of line 0 unless they special-case a zero count.
Neither version ends with a newline, so the marker appears twice in one hunk: once after the last removed line and once after the last added line. Parsers that treat the marker as a terminator rather than an annotation stop reading at the first one and lose the added line.
A one-line file is edited and loses its trailing newline in the process, so the marker follows the `+` line instead of the `-` line. Applying this and then re-diffing must not reintroduce the newline.
The before-state has no final newline and the after-state gains one, so the marker appears once, immediately after the last `-` line. The change is invisible in a rendered side-by-side view yet alters the file's bytes, which is why line-based comparators report a spurious no-op.
With git's default `core.quotepath`, a path containing non-ASCII bytes is wrapped in double quotes and each byte is written as a backslash-octal escape. A parser that takes the header text literally creates a directory called `caf\303\251` on disk.
A patch as it actually arrives in a mailing-list message: prose above it, a sign-off and an email signature below it, and a signature separator that looks like the start of a deletion. Extractors must find the diff without swallowing the surrounding text.
The same change with `core.quotepath=false`, so the path is written as raw UTF-8 and the header is not quoted. Compare with the quoted twin to confirm a parser resolves both spellings to the same file.
The exact inverse of the single-hunk fixture: the same edit expressed as a deletion instead of an insertion. Applying both in sequence must return the file to its original bytes, which makes this the fixture for `patch -R` and for revert paths.
One TypeScript module edited in 2 places at once, so the hunks are far enough apart not to merge. Use it to check that a parser advances its line cursor by the hunk header rather than by counting emitted lines.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
