uri-template-lite

uri-template-lite implements the RFC 6570 URI Template specification in a single, compact JavaScript file with no runtime dependencies. It exposes both a static expand() function for one-off template expansion and a Template constructor that precompiles a template into a matching regular expression and an expansion function, so repeated calls against the same template pattern avoid re-parsing.

Beyond expansion, the library supports the reverse operation: extracting variables back out of a concrete URI via template.match(), using the same compiled template. This dual expand/match capability, combined with its small footprint, makes it a lightweight alternative to heavier RFC 6570 implementations for projects that need both directions of URI templating without pulling in a large dependency.

What You Get

• A static UriTemplate.expand(template, data, opts) function for direct, one-shot template expansion without instantiating an object
• A Template constructor that precompiles a URI template into a cached regular expression and expansion closure for repeated use
• Bidirectional support: expand() to build URIs from data and match() to extract variables from URIs back into a data object
• Support for the full range of RFC 6570 operators (+, #, ., /, ;, ?, &) covering reserved expansion, fragments, path segments, path-style parameters, query parameters, and continuation
• Configurable encoder/decoder options for custom value encoding and decoding during expand/match
• Best-effort error handling that leaves malformed template expressions (like {unclosed) untouched in the output instead of throwing

Common Use Cases

• Building REST/HTTP client URLs from a templated endpoint definition plus a params object
• Implementing hypermedia (HATEOAS) link expansion where APIs return RFC 6570 templates that clients must fill in
• Parsing route-like URIs back into structured parameters using match() instead of a separate router library
• Generating OpenAPI/Swagger-style parameterized URLs at runtime from a single template string
• Any project that wants RFC 6570 compliance without adding a heavier templating or routing dependency

Under The Hood

Architecture The entire library lives in a single self-invoking function in index.js that attaches Template and Template.expand to module.exports. The static expand() function walks the template string with a regular expression (expandRe) matching RFC 6570 expression blocks and replaces each one inline using a per-operator separator table (SEPARATORS). The Template constructor takes a different approach: it walks the template once with a broader regex (parseRe) and, for each expression, both builds up a matching regular expression string (reStr) and accumulates a snippet of JavaScript source (fnStr) that will extract the corresponding variables. It then calls the Function constructor to compile that accumulated source into a real function (fn), so a single template pays the parsing cost once and reuses a compiled regex plus a compiled extraction function on every subsequent match() call. There is no external state, no classes beyond the one constructor, and no dependency injection — it is a pure, self-contained parser/compiler pair.

Tech Stack The package has no runtime dependencies at all — package.json lists only a single devDependency, @litejs/cli (the author’s own lj t test runner), used purely for running the test suite via npm test. The code targets ES5 (the .jshintrc-equivalent config in .github/jshint.json sets esversion: 5), uses module.exports for CommonJS interop, and relies on browser/Node built-ins (encodeURIComponent, decodeURIComponent, RegExp, Function) rather than any framework. There is no build step or bundler configured; the single index.js file is published as-is.

Code Quality Tests live under test/index.js and run through the author’s own @litejs/cli (lj t) test runner rather than a mainstream framework like Jest or Mocha, using a describe/it style with data-table-driven test cases. Test coverage draws on two sources: a custom test/custom-examples.json fixture and a git submodule (test/uritemplate-test) pointing at the community uri-templates/uritemplate-test conformance suite, which runs the official RFC 6570 Level 1-4 test vectors against both expand() and match(). Linting is configured via jshint with undef/unused checks enabled. There are no TypeScript types or type definitions shipped, and error handling is intentionally permissive (malformed expressions pass through rather than throwing) rather than strict.

What Makes It Unique Most RFC 6570 implementations only support one direction — expanding a template into a URI. uri-template-lite additionally compiles each template into a matching regular expression plus a synthesized extraction function via Function(), allowing the same template to be used to pull structured variables back out of a concrete URI via match(). Combined with its single small file and zero dependencies, this bidirectional expand/match support in such a compact package is its main differentiator versus larger, expand-only URI template libraries.