Convert a Version List Into a TypeScript Union, JSON, CSV, or SQL IN

Every codebase eventually grows a "supported versions" list that lives in three or four places at once: a TypeScript type, a CI matrix, a database lookup, and a row in some release spreadsheet. Keeping those copies in sync by hand is where the typos creep in. You quote 1.0.0 correctly in the union type, forget a comma in the JSON array, and then a release goes out claiming support for a version you never actually tested.

The Semantic Version List Converter exists to make that copying mechanical. You paste a plain list of versions, and it re-emits the same tags in whichever shape your next file needs. The parser runs entirely in the browser, so a private internal version list never touches a server.

What this tool actually outputs

There is no guessing about supported formats, so let me be exact. From one pasted list, this converter produces six outputs:

• Plain lines — the cleaned, one-per-line list.
• CSV — a quoted column you can drop into a spreadsheet export.
• JSON — a JSON array of strings.
• Markdown — a list or table for release notes and docs.
• SQL IN — a parenthesized, comma-separated set for a WHERE version IN (...) clause.
• TypeScript union — a string-literal union type like '1.0.0' | '1.1.0' | ....

That is the full set. The same local parser feeds every format, so the tokens are identical across outputs; only the punctuation around them changes. You can also keep unique rows only, preserve invalid rows for review with the reason attached, and sort the normalized result before you export.

A list of versions becomes a TypeScript union in one step

Here is the concrete win. Say you maintain a SupportedVersion type and you currently have this in a text file, one tag per line:

1.0.0
1.1.0
1.2.0
2.0.0
2.1.3

Paste that into the converter, pick TypeScript union, and you get:

'1.0.0' | '1.1.0' | '1.2.0' | '2.0.0' | '2.1.3'

Drop that straight into a type alias:

type SupportedVersion = '1.0.0' | '1.1.0' | '1.2.0' | '2.0.0' | '2.1.3';

Now switch the output to JSON on the same input and you get the matrix-ready array:

["1.0.0", "1.1.0", "1.2.0", "2.0.0", "2.1.3"]

That array goes directly into a GitHub Actions strategy.matrix.version field, or into a fixture your tests iterate over. No hand-quoting, no chasing a missing comma at the end of line three. The whole point is that the union type and the CI array come from the same source of truth, separated by one dropdown click instead of two rounds of manual editing.

Release matrices, CI configs, and database lookups

Once you treat your version list as data rather than text, the other formats fall into place:

• CI matrices. A test matrix that runs your suite against each supported runtime version wants a JSON array. Export JSON, paste it under matrix, done. When you drop a version, delete the line and re-export — the array stays consistent.
• Database queries. Need to pull rows for a set of releases? Export SQL IN and you get ('1.0.0', '2.0.0', '2.1.3') ready to paste into a WHERE version IN (...) clause, with the quoting handled for you.
• Release docs. Export Markdown for a changelog table or a "compatible versions" bullet list that you can paste straight into a .md file.
• Spreadsheet handoff. Export CSV when a product manager or release owner wants the list in a sheet, with each version in its own quoted cell.

The tool is deliberately format-agnostic about the destination. It does one job — turn a verified list of versions into the exact artifact the next file expects — and stays out of everything else.

Keeping the messy inputs honest

Real version lists rarely arrive clean. They come from git tag dumps, copied web pages, package-manifest exports, and support tickets, and they carry duplicates, stray whitespace, and the occasional malformed tag. The converter handles that without you babysitting it:

• Deduplicate so a tag that appears in two exports collapses to one row.
• Sort the normalized output so diffs stay small between releases.
• Keep invalid rows when you want them. A token like v1 or 1.0.0-+ is something a downstream parser would reject; the converter can carry it through with the reason attached so you spot the gap instead of silently dropping it.

One caution worth repeating: text copied from a web page often hides non-printing whitespace, so normalize before you deduplicate or import. If you only need one of these steps on its own, the dedicated semantic version normalizer and semantic version deduplicator cover those single jobs, and the semantic version list validator flags which tags would fail before you convert anything.

How I use it

I keep a supported-versions.txt scratch file in one of my projects, and every release I add or remove a line. When the type needs updating, I paste the file in, switch to TypeScript union, and replace the body of my SupportedVersion alias in one go. Then — without changing the input — I flip to JSON and paste that into the CI matrix. What used to be two separate hand-edits, each with its own chance to fumble a quote, is now one paste and two dropdown clicks. The first time a teammate's PR failed CI because the matrix and the type disagreed, I realized the value was never the conversion itself; it was that both outputs come from the same list, so they cannot drift apart.

When to reach for a sibling tool

This converter is the general-purpose hub, but the family is split into focused tools. If your version strings are buried inside a larger blob of log text or copied HTML, start with the semantic version extractor to pull just the tags out first, then bring the clean list back here to convert. For the inverse direction — turning tabular data into docs — csv-to-markdown-table handles spreadsheet-to-Markdown conversion that pairs well with the version tables you export here.

The common thread across all of them: the parsing, validation, deduplication, and download run locally in your browser, and uploaded text files are read with the File API rather than sent anywhere. For an internal version index that names unreleased builds, that local-only guarantee is the difference between a quick cleanup and a data-handling review.

Pick the format your next file needs, paste once, and let the punctuation be the tool's problem instead of yours.

---

Made by Toolora · Updated 2026-06-13