Trusted Library Ecosystem

[eladb]

Community Note

Please vote by adding a 👍 reaction to the issue to help us prioritize.
If you are interested to work on this issue, please leave a comment.

Feature Spec

Originally #652

A wing library is a collection of types that can be used by other wing libraries or apps.

Open-source supply-chain attacks are becoming one of the most common and dangerous attack vectors in the industry. To increase the trust, safety and quality of the wing library ecosystem, wing takes a unique approach to package publishing.

The basic idea is that "trusted" winglang libraries are normal npm packages that are published under the @winglang scope, and their code is hosted under the winglang github org. These libraries can be authored by anyone but they are always published by the winglang project and not their authors.

This serves two purposes:

1. It simplifies publishing. The wing publishing system takes care of release management, versioning, backwards compatibility checks, changelogs, etc.
2. It increases trust and quality of the ecosystem using a low friction peer-review system.

We need to decide on the right name that sets the right expectation: "trusted", "community", "approved", "peer-reviewed", something like that. For the sake of this document, I'll call them "trusted".

Let's walk through the user experience of installing and publishing trusted and untrusted wing libraries.

Installing wing packages

To install a trusted wing package, use:

wing install redis
# or
wing i redis
# or
wing i redis@^2

Use it like so:

bring redis;
bring cloud;

let db = new redis.Database();

new cloud.Function(inflight () => {
  db.hset("my_hash", "my_key", "my_value");
});

Under the hood, wing uses npm to install the package @winglang/redis into your package.json.

Publishing trusted wing packages

To publish a new trusted wing library, all you have to do is simply submit a pull request to the https://github.com/winglang/libs repository.

This repository includes a directory for each library, and is already set up to take care of builds, tests and releases. Just put your code in the right place and we'll take care of the rest.

Your pull request will be go through a quick review by one of our community members. The purpose of this review is to help you make your library awesome and that it meets the wing standards. Once reviewed, it will be merged and immediately released.

Out of the box best in class library publishing

The following will automatically happen for all libraries in the trusted namespace:

1. Compile
2. Unit test
3. Cloud testing (runs on all supported target platforms of the library)
4. Generation of API documentation
5. Require a major version bump for breaking api changes (like jsii-diff).
6. Automatic version bumps based on commit history and api breaking changes (versions are tagged automatically in the repo)
7. Changelog
8. Tweet on each release
9. Discoverable/installable through the wing vscode extension
10. Listed in the "Wing Candy Store" (online package repository), including api documentation of course
11. wing help foo shows api docs
12. More!

In the future, we will add support for self-service creation of new repository in the winglang github organization, and each library will have its own repository, but for now a single mono repo will make things much easier for everyone and will increase the cohesiveness of the ecosystem.

Untrusted libraries

Again, name pending.

As mentioned above, winglang libraries are simply npm (JSII) packages, so anyone can publish anything to npm.

You can then use npm to install this library:

npm i my-wing-lib

And use bring like normal:

bring "my-wing-lib" as mwl;

mwl.print_hello();

But:

$ wing compile hello.w
ERROR: trying to bring untrusted library "my-wing-lib". Use --allow-untrusted=my-wing-lib to allow.

So you'll have to explicitly opt-in to allow this library:

$ wing compile hello.w --allow-untrusted=my-wing-lib

Use Cases

• A library ecosystem for Wing

Implementation Notes

No response

Roadmap

P1

• Set up canary that periodically checks all winglibs work with the latest wing toolchain #5263

P2

• Use mergify in winglibs repo #5264
• Generate API docs for Wing libraries #4449
• Include winglibs docs on the docsite #5225
• Show published winglibs as autocomplete suggestions for bring statements #5265
• Manage package versions automatically in winglibs repo #5271
• Set up cloud testing in winglibs repo (run tests in CI/CD against tf-aws and other targets)

P3

• Create dedicated page on Wing's docsite for discovering libraries
• Add tab to Wing VS Code extension for browsing Wing trusted libraries
• wing help foo shows API docs
• Automatically post new winglibs on X/Twitter and the Wing slack

[staycoolcall911]

This is a duplicate of #130

[eladb]

I wouldn't say that this is a duplicate. This is about the "managed ecosystem" of libraries while #130 is just the mechanism in the language.

[staycoolcall911]

Got ya

[Chriscbr]

Chunking up some of the feature ideas above into tasks:

• Set up canary that periodically checks all winglibs work with the latest wing toolchain #5263
• Use mergify in winglibs repo #5264
• Generate API docs for Wing libraries #4449
• Include winglibs docs on the docsite #5225
• Show published winglibs as autocomplete suggestions for bring statements #5265
• Manage package versions automatically in winglibs repo #5271
• Create dedicated page on Wing's docsite for discovering libraries
• Add tab to Wing VS Code extension for browsing Wing trusted libraries
• wing help foo shows API docs
• Automatically post new winglibs on X/Twitter and the Wing slack
• Set up cloud testing in winglibs repo (run tests in CI/CD against tf-aws and other targets)

[staycoolcall911]

Added a prioritized roadmap at the end of the issue description based on Chris's excellent list.