# Wing: a language whose compiler runs your code, and the last release is twenty months old

> A cloud language with two execution phases, preflight at compile time emitting Terraform or CloudFormation and inflight compiled to JavaScript for Node.js, plus eleven dependency security floors, four Rust crates beside a projen generated TypeScript workspace, and a licence field with no assertion. It also still describes itself as a pre-release.

**winglang/wing** — A programming language for the cloud ☁️ A unified programming model, combining infrastructure and runtime code into one language ⚡

- Repository: https://github.com/winglang/wing
- Website: https://winglang.io
- Stars: 5,401 · Forks: 216
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/winglang-wing

## The compiler executes your code, and it executes it in a phase you did not choose

Wing has two execution phases, and the split is the language. Preflight code is executed during compilation and produces the infrastructure configuration for the app, in formats like Terraform and CloudFormation. Inflight code is compiled into JavaScript and executed within cloud compute platforms in Node.js environments.

So a single program has two lives. Part of it runs on your machine when you build, against no cloud account, and its output is a configuration file. Part of it is turned into JavaScript and runs later, somewhere else. Nothing about that is unusual in principle; what is unusual is that the language knows the difference and checks you.

It also means a compile is not a type check. Compilation here has side effects and produces deployable artifacts, which is worth remembering before you wire the compiler into anything that runs on every keystroke.

## One object, two method sets, and only one of them is reachable at run time

The example the page builds up is the clearest statement of the idea. Three objects are created in preflight:

```js
bring cloud;

let queue = new cloud.Queue();
let counter = new cloud.Counter();
let bucket = new cloud.Bucket();

queue.setConsumer(inflight (message) => {
  let i = counter.inc();
  bucket.put("file-{i}.txt", message);
});
```

cloud.Queue, cloud.Counter and cloud.Bucket are preflight objects representing cloud infrastructure resources, and when compiled for a provider such as AWS a Terraform file is produced with that provider's implementation of them. setConsumer is a preflight method: it configures the infrastructure to invoke a particular inflight function for each message in the queue.

Inside the callback, the same counter and bucket objects are used again, now through their inflight methods, counter.inc() and bucket.put(). Those methods can only be called from inflight scopes. Same object, two method sets, one rule.

## The stated reason for being a language rather than a library

There is a section on the front page headed with a question about what here cannot be done by a library or a compiler extension, and it is the most important paragraph on the page for anyone deciding whether they need a new language at all.

The argument is this: in existing languages there is no way to distinguish between multiple execution phases, and without that distinction it is impossible to naturally represent the idea that an object has methods which can only be executed from within a specific execution phase, or within certain scopes of the program.

That is a narrow, testable claim, and the page links a page of samples showing the same application built in Wing and in other solutions. If your objection to Wing is that a framework could do this, that page is the place the objection gets tested. If your objection is that you would rather not adopt a language to get it, then this section explains what you are giving up and what you are getting.

## It still says pre-release, and the last tag is from February 2025

The getting started section opens with a construction sign and one line: this is a pre-release, with a link to the project status page for details.

The release history says the same thing in a different way. v0.85.49 is dated 2025-02-03, v0.85.48 on 2025-01-28 and v0.85.47 on 2025-01-20. The newest recorded commit is 2026-09-29. So the last three tags arrived within two weeks of each other at the start of 2025, and the repository has taken commits for the twenty months since without cutting another.

That combination is not inactivity. It is a project that is working on main while telling you not to depend on a release. For anyone planning real work, the practical consequence is that you build from a commit or you wait, and the status page rather than the tag list is the place to find out which is currently true.

## Rust crates beside a projen generated TypeScript workspace

The repository root is a hybrid, and the file list shows it. On the JavaScript side there is a pnpm workspace, a turbo.json, a package.json that is private and versioned 0.0.0, and a .projenrc.ts, which is the tell: projen generates the project configuration, and the build script is projen build with projen compile alongside it.

On the Rust side there is Cargo.toml, Cargo.lock, rust-toolchain.toml, .rustfmt.toml and a .cargo directory, and the workspace declares four members: packages/wingcli-v2, packages/@winglang/tree-sitter-wing, packages/@winglang/wingc and packages/@winglang/wingii. Cargo.toml also carries a profile named flamegraph that inherits release with debug enabled, commented as being for cargo flamegraph.

The rest of the root is testing and tooling: an .insta.yaml for snapshot tests, a patches directory for patched dependencies, a devcontainer, a .vscode directory, a wing.code-workspace, and a wing-console directory, meaning the visual operations console the feature list advertises lives in this repository rather than elsewhere. Four ways of saying which Node version to use also sit at the root.

## Eleven dependency overrides, every one of them a lower bound

The package manifest carries a pnpm overrides block, and it is not a list of preferences. Every entry raises a floor above a range that was known to be bad. mime goes to 3.0.0. axios is covered twice, once lifting the 0.8.1 to 0.28.0 range to 0.28.0 through 1.0.0 and once lifting 1.0.0 to 1.16.0 to 1.16.0 through 2.0.0. Then ajv to 6.14.0, ip-address to 10.3.1, js-cookie to 3.0.7, pacote to 21.5.1, sigstore to 4.1.1, tmp to 0.2.6, @grpc/grpc-js to 1.10.12 and @trpc/server to 10.45.3.

Two things follow. The duplicate axios entry is the interesting one, because it shows the list being maintained against two major ranges at once, which is the maintenance cost of a floor-based policy. And the block is the clearest statement of the project's own posture towards its dependency tree: it is pinned from below for safety rather than from above for reproducibility, so your lockfile is still the thing that decides what you get.

The manifest also names four Node pins in different formats, a packageManager field, a volta block with node 20.17.0 and pnpm 8.15.1, plus .node-version and .nvmrc at the root.

## Install runs a WASI setup script and postinstall links workspace binaries

Three lifecycle scripts shape what a contributor has to have before anything builds. preinstall runs npx only-allow pnpm, which turns the wrong package manager into an error rather than a subtly different tree. install runs bash scripts/setup_wasi.sh. postinstall runs link-bundles and then generate-workspace.

The WASI script is the one with the widest blast radius, since it runs on every install and is a shell script, so it assumes a POSIX shell. The devcontainer at the root is the answer to that, and the Volta block pinning node 20.17.0 is the answer on the JavaScript side.

The postinstall pair is smaller but worth reading closely. generate-workspace is declared as a workspace dev dependency, while link-bundles is not in that list at all, so one of the two commands comes from somewhere the manifest does not name directly. Both are followed by the wing script, which compiles the winglang package through turbo and then runs ./packages/winglang/bin/wing, so the local CLI is always built from source rather than installed.

## A licence field with no assertion and four legal files at the root

The licence metadata for this repository records no assertion. The root of the tree contains LICENSE.md. Both facts come from the repository and this article will not reconcile them by choosing one, because the file exists and the metadata declines to say what it is.

Around that sit more legal files than most projects have: CONTRIBUTION_LICENSE.md, CONTRIBUTORS_TERMS_OF_SERVICE.md, Privacy.md, SECURITY.md, CODE_OF_CONDUCT.md and CONTRIBUTING.md. A separate licence covering contributions and a separate terms of service aimed specifically at contributors is an unusual amount of paperwork for a pre-release compiler, and it suggests the project is preparing for outside code rather than expecting to be ignored.

One absence is worth noting as well. There is no contributors list file at the root, even though there is a terms of service for contributors. The community is pointed at a Discord invite and the page calls its contributors the Wingnuts, so recognition lives in chat rather than in the repository.

## Conclusion

Wing is worth reading for one idea, which is that an object can carry one method set for build time and another for run time, and that the language enforces which one you are holding. That idea is not available to a library or a compiler extension, which is the argument the project makes and the reason it is a language rather than a tool. Two practical cautions come with it. The status is pre-release by the project's own banner, and the newest listed tag is v0.85.49 from 2025-02-03 against a newest recorded commit of 2026-09-29, so plan on building from a commit rather than pinning a release. And settle the licence yourself, because the metadata records no assertion while the root carries LICENSE.md alongside a separate contribution licence and a contributors terms of service, and this article will not tell you which one governs your use.

## FAQ

### What is the Wing language and what is it for?

Wing is a new open source programming language designed for the cloud, which combines infrastructure code and application code in one safe, unified programming model. Programs can be executed locally with a fully functional simulator and no internet required, or deployed to any cloud provider, since Wing programs are portable across providers.

### What are preflight and inflight in Wing?

They are the two execution phases. Preflight code is executed during compilation and produces the infrastructure configuration, in formats such as Terraform and CloudFormation. Inflight code is compiled into JavaScript and executed within cloud compute platforms in Node.js environments.

### Do I need a cloud account to try Wing?

No. Wing programs can be executed locally using a fully functional simulator, with no internet required, and there is an online playground and an interactive tour linked from the front page for trying the language before installing anything.

### Is Wing finished, or should I wait before using it?

The getting started section states that it is a pre-release and links to a project status page. The newest listed release is v0.85.49 from 2025-02-03 while the newest recorded commit is 2026-09-29, so building from a commit is the realistic option today.

### What is written in Rust inside the Wing repository?

Cargo.toml declares four workspace members: packages/wingcli-v2, packages/@winglang/tree-sitter-wing, packages/@winglang/wingc and packages/@winglang/wingii. The rest of the project is a TypeScript pnpm workspace orchestrated by turbo, with projen generating the project configuration from .projenrc.ts.

## Sources

- [Issues](https://github.com/winglang/wing/issues)
- [Project website](https://winglang.io)
- [README](https://github.com/winglang/wing/blob/main/README.md)
- [Releases](https://github.com/winglang/wing/releases)
- [winglang/wing on GitHub](https://github.com/winglang/wing)

---

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