# Pomsky Regex Language: Portable Compilation and Diagnostics

> Pomsky compiles a shared regular expression source for PCRE, JavaScript, Java, .NET, Python, Ruby, Rust, and RE2. It suits developers who need target validation, but Unicode settings and documented portability exceptions still affect adoption.

**pomsky-lang/pomsky** — A new, portable, regular expression language

- Repository: https://github.com/pomsky-lang/pomsky
- Website: https://pomsky-lang.org
- Stars: 1,352 · Forks: 21
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/pomsky-lang-pomsky

## Pomsky's Cross-Engine Regex Problem

Pomsky addresses a concrete portability problem: services in different languages often use regular expression engines with different syntax and supported features. A pattern written for PCRE may not be accepted by RE2, while a construct accepted by JavaScript may behave differently in Python, Java, Rust, or .NET. Maintaining several handwritten expressions increases the chance that a rule will drift as it moves between systems.

Pomsky introduces a shared regular expression language between the developer and those engines. According to the README, it can generate expressions for PCRE, JavaScript, Java, .NET, Python, Ruby, Rust, and RE2. The target flavor must be specified during compilation. That requirement is important because Pomsky uses the selected flavor to reject unsupported features rather than claiming that every expression works everywhere.

The project is primarily written in Rust. Its Cargo workspace contains `pomsky-bin`, `pomsky-lib`, `pomsky-syntax`, and `pomsky-macro`, along with help, test, benchmark, and WebAssembly components. This layout indicates a command-line compiler backed by reusable Rust packages. The repository also links to a Playground, website documentation, and a Visual Studio Code extension.

The intended users are developers and teams that define a matching rule once but need it in several environments. Examples include services with mixed runtimes, tools that generate regex configuration, and projects that want target-specific validation before deployment. Pomsky is not itself a regex execution engine. It parses and compiles an expression into syntax intended for another engine, which must still perform the actual matching.

## Pomsky Compilation and Diagnostic Flow

The documented compiler flow starts with a Pomsky expression and a selected regex flavor. Pomsky parses that expression, checks whether its features are supported by the target, and produces a regular expression for the intended engine. The README says the compiler reports an error when a feature is unavailable in the selected flavor. That check makes the target part of the build contract rather than an incidental output setting.

The compiler also provides several diagnostics for common authoring mistakes. According to the README, it identifies syntax errors, offers suggestions, explains backslash escapes that are invalid in Pomsky, and warns about likely mistakes. These checks apply to the source language, while the selected regex flavor determines whether an otherwise valid Pomsky feature can be generated for the destination.

The README also discusses diagnostics for patterns that may run slowly on certain inputs. However, it marks Denial-of-Service pattern detection as "coming soon." That means this functionality should not be treated as a complete current defense. Security documentation separately warns that compiling or executing an untrusted Pomsky expression can enable denial-of-service attacks such as Billion Laughs.

Based on the repository layout, `pomsky-syntax` handles the language side of the workspace, `pomsky-lib` provides library components, and `pomsky-bin` packages the command-line application. The README does not document the internal function calls, so adoption should not depend on a guessed Rust API. Users who need library integration must inspect the current `pomsky-lib` interface directly.

## Installing Pomsky from Source

The README says to install a recent Rust toolchain and then run this Cargo command. It installs the published `pomsky-bin` package into the Cargo installation environment.

```bash
cargo install pomsky-bin
```

After installation, the executable should be available from the directory configured for Cargo-installed binaries. The README does not provide a first compile command, target option, or complete CLI example. It directs new users to the website documentation, so this article does not invent an option name that may not match the installed version.

The repository's `justfile` defines a separate installation recipe for developers working from a checkout. Run this from the repository root to build and install the local `pomsky-bin` package rather than the published package.

```bash
just install
```

The recipe expands to the following Cargo command:

```bash
cargo install --path=pomsky-bin
```

A checkout uses edition 2024 according to the workspace configuration, so the installed Rust toolchain must support that edition. The README also lists prebuilt binaries, shell and PowerShell installers, a Windows MSI installer, the `@pomsky-lang/cli` NPM module, and the `pomsky-bin` AUR package. The releases page contains the corresponding installation instructions. These channels are useful when editing or installing an existing Rust toolchain is inconvenient.

## Starting a Target-Aware Pomsky Workflow

The first real use should be planned around target selection. Decide which regex engine will execute the generated expression, check that the engine supports Unicode, and write one small Pomsky expression in the website Playground. The README confirms that the Playground exists, but it does not document button labels, menu names, or sample expressions. Those interface details must be taken from the current website rather than inferred here.

A useful first verification is a pattern with straightforward literal text, followed by compilation for every engine named in the README. Record the generated output for each target and run the application's existing tests against it. The goal is not to compare formatting alone. Check the rule's intended semantics, especially when text can contain non-ASCII characters.

Pomsky warns users to enable Unicode support in the target engine when it is not enabled by default. A project should therefore record that setting alongside the selected Pomsky target. Otherwise, two systems may receive generated expressions for nominally compatible engines but still disagree because their underlying matching modes differ.

The README does not publish a minimal command-line expression or the exact option for selecting a target. It does not document rollback either. For a command-line rollout, consult the version-specific website documentation and releases page, then check the local help output after installation. For an editor rollout, the linked Visual Studio Code extension may provide syntax support, but the README does not state which compiler version or target configuration it uses.

## Portability Limits and Pomsky Security Boundaries

Pomsky does not make portability unconditional. The README states that a few kinds of Pomsky expressions are not portable and links to a dedicated portability appendix. It also identifies Unicode configuration as a target-side requirement. Teams should review both points before standardizing Pomsky across services.

The target list in the README covers eight regex environments, but naming an environment does not mean that all Pomsky features are equally suitable for it. Compilation is where the project checks target support. Existing patterns should therefore be compiled and tested for each intended engine rather than assuming that successful compilation for one engine guarantees identical matching elsewhere.

Security creates a firmer restriction. The README explicitly says never to compile or execute an untrusted Pomsky expression on critical infrastructure. Expressions from users, uploaded documents, plugins, or remote configuration fall into that boundary unless another mechanism establishes trust. Pomsky's pattern analysis does not replace application isolation because the README labels Denial-of-Service detection as forthcoming.

Runtime resource controls also remain outside the documented compiler guarantees. The target regex engine still determines how much CPU and memory a match can consume. Pomsky is best treated as an authoring and compilation layer for trusted expressions, not as a public input service.

## Pomsky Compared with Direct Engine Patterns

The main alternative is direct authoring in the target engine's native regex syntax. For an application that uses only one runtime, a direct pattern avoids learning a separate language and removes the compilation step. It also gives immediate access to every documented feature of that engine and avoids questions about whether Pomsky can represent the required construct.

Pomsky takes a different approach. A shared Pomsky expression becomes the authoring source, and the selected flavor determines the generated output. Its diagnostics can reject unsupported features before deployment, while one source expression can target several listed engines. This trade-off is most useful when the matching rule is maintained across multiple services or generated configuration files.

The added compiler is also a cost. Developers must understand Pomsky syntax, select the correct flavor, verify Unicode behavior, and account for the documented non-portable cases. Security-sensitive services face the stronger rule against compiling untrusted expressions. A small direct regex can therefore remain preferable when one engine controls the entire deployment and the extra abstraction has no clear benefit.

Pomsky is dual-licensed under the MIT license or the Apache 2.0 license. The repository contains `LICENSE-MIT` and `LICENSE-APACHE`. That gives users a stated licensing choice, while each adopter still needs to check notices and dependency terms relevant to its distribution model.

## Pomsky Release and Upgrade Boundaries

The repository is not archived, and the last push was on 2026-04-23. The latest listed release is v0.12.0 from 2025-11-08. Earlier listed releases are v0.11 from 2023-11-09 and v0.10 from 2023-03-21. The change in cadence makes `CHANGELOG.md` particularly relevant when moving from an older release to v0.12.0.

The workspace separates the syntax, library, command-line, and macro packages. Its `bump-versions` recipe updates `pomsky-syntax`, `pomsky-lib`, `pomsky-bin`, and `pomsky-macro` together. The publishing workflow also lists those packages in sequence, which indicates coordinated crate releases. Consumers still need compatible versions of the packages they include.

The README does not provide a compatibility policy between Pomsky versions. Before upgrading a production build, compile existing expressions again, compare generated regexes for every target, and run the matching tests used by the application. Pay particular attention to Unicode configuration and any behavior covered by the `CHANGELOG.md` entry for the destination version.

## Conclusion

Developers maintaining regexes across several runtimes should adopt Pomsky after reviewing its portability rules and testing representative expressions against every intended target. Projects that need one small pattern for a single engine should usually write it directly in that engine. The first verification is target selection and Unicode configuration, because compilation alone cannot make differing engine settings behave identically.

## FAQ

### How do I install Pomsky from source?

Install a recent Rust toolchain and run `cargo install pomsky-bin`. For a local checkout, the repository's `justfile` also provides `just install`, which runs `cargo install --path=pomsky-bin`.

### Which regular expression engines does Pomsky support?

The README lists PCRE, JavaScript, Java, .NET, Python, Ruby, Rust, and RE2. The target regex flavor must be specified during compilation.

### Is every Pomsky expression portable?

No. The README refers to documented situations where Pomsky expressions are not portable. It also advises enabling Unicode support in the target engine when necessary.

### Can Pomsky compile expressions supplied by untrusted users?

The README warns against compiling or executing untrusted Pomsky expressions on critical infrastructure because this can enable denial-of-service attacks.

### Under which licenses is Pomsky available?

The README states that Pomsky is dual-licensed under the MIT license or the Apache 2.0 license. The repository contains both `LICENSE-MIT` and `LICENSE-APACHE`.

## Sources

- [License: Apache-2.0](https://github.com/pomsky-lang/pomsky/blob/main/LICENSE)
- [pomsky-lang/pomsky on GitHub](https://github.com/pomsky-lang/pomsky)
- [Project website](https://pomsky-lang.org)
- [README](https://github.com/pomsky-lang/pomsky/blob/main/README.md)
- [Releases](https://github.com/pomsky-lang/pomsky/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pomsky-lang-pomsky