feat(compiler): multi-file Wing applications

[Chriscbr]

Introduce a basic form of multi-file Wing projects through the bring keyword. To use classes, interfaces, enums, or structs from another Wing file, bring a file with a path that ends in .w, and assign it to an alias:

bring "./other-file.w" as shared;

new shared.Store();

This initial implementation follows a (naive) strategy of recursively instantiating the parser to create a large AST. This has some limitations -- for example it's not possible for two Wing files to reuse the same third Wing file -- but this still gives users a lot more refactoring power for building Wing apps. #3511 is the main follow-up issue for addressing this.

Closes #476

Follow up:

• Bad error message on bring/import cycles #3509
• Cannot reuse dependency that is used elsewhere (diamond dependency problem) #3511

Checklist

• Title matches Winglang's style guide
• Description explains motivation and solution
• Tests added (always)
• Docs updated (only required for features)
• Added pr/e2e-full label if this feature requires end-to-end testing

By submitting this pull request, I confirm that my contribution is made under the terms of the Monada Contribution License.

[Chriscbr]

@MarkMcCulloh raised an important issue which is that before shipping this, we should aim to have a solution which prevents imports from having side effects. For example, with this PR the following code would be valid:

// file1.w
bring "./file2.w" as file2;

// file2.w
bring cloud;

let global_bucket = new cloud.Bucket();
class B {
  // uses global_bucket
}

However, notice that bringing file2.w into the first file has the side effect of creating a bucket in the user's application, even though no classes from that module actually gets constructed (such as B). In some past discussions it's been brought up that only the entrypoint Wing file should have an implicit scope, so I'd like to see if there's a way to incorporate that here.

[eladb]

prevents imports from having side effects. For example, with this PR the following code would be valid.

Totally. We discussed this a few times. Non-entrypoint files should not allow any root-level statements, only type declarations (class, enum, interface and struct).

In the future (let's open a tracking issue) we want to support constants as root level statements in non-entrypoint files - let statements with an immutable data type (primitives or immutable collections).

I think we can do this as a quick follow up to this PR if it gets hairy, but let's make sure to prioritize it.

[mergify]

Thank you for contributing! Your pull request will be updated from dev and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[staycoolcall911]

This is incredible! So needed...

[monadabot]

Congrats! 🚀 This was released in Wing 0.24.41.