Keep track of file package scope(user project, library, compiler, etc.)

[Timothee Guerin (timotheeguerin)]

This is a key piece to ensure a linter can omit warnings in non project code.

The resolution goes as follow:

• start in project scope
• if loading a directory or library that has a package.json set scope to that library. If library loads another library update the scope to be the nested library.
• when loading compiler files set scope to compiler

Questions to answer:

• Do we need to expose that on the type or have an helper to see what are the scope(s) of a type

[github-actions]

Changes in this PR will be published to the following url to try(check status of TypeSpec Pull Request Try It pipeline for publish status):
Playground: https://cadlplayground.z22.web.core.windows.net/prs/2031/

Website: https://cadlwebsite.z1.web.core.windows.net/prs/2031/

[Timothee Guerin (timotheeguerin)]

This is the current behavior. It is not very nice to not have consistency here but at the same time this might be sign of a bad design from project structure.

Alternative would be to always promote to the project scope if it is part of it in any way

[Brian Terlson (bterlson)]

Overall, the notion of hooking module resolution to establish a map of sourceFile -> "project" | "compiler" | "library" feels good.

Some thoughts:

1. I'm not sure I like using the word "scope" here. Like, the scope of a type is quite literally the container it is declared in. Consider something more descriptive? (Will also ponder).
2. Should be an API that takes a type and returns its scope
3. Need to figure out what to do with types which don't correspond to AST nodes, e.g. "virtual" types constructed via projections. I think there are cases where the node property on types is undefined.

[Nick Guerrera (nguerrera)]

"Domain"?

[Brian Terlson (bterlson)]

I like domain, ish? But considering "Realms" is coming, "domains" and "realms" might be a bit much? Or we go all in and have features named "kingdoms", "fiefdoms", etc.? :-D

Could also just be super descriptive - LocationContext or something like that?

[Timothee Guerin (timotheeguerin)]

I tried naming it DeclarationDomain but yeah DeclarationContext or LocationContext could work.

[Nick Guerrera (nguerrera)]

That works for me too.

(Separately, my mind is wandering, thinking about a new name for the whole project where we lean into having "kingdoms" and "fiefdoms".)

[Timothee Guerin (timotheeguerin)]

dom establish .

ally "@typespec/http";

trade Typespec.Http;

kingdom MyService.Foo {
  knight Foo {
     knighHaveProperties: string;
  }
}

[Brian Terlson (bterlson)]

Timothee Guerin (@timotheeguerin) Ok but this is actually really good! I think we have our April Fools joke for next year?? Could pretty easily be supported 😈

My issue with DeclarationX is that I think we will want to pass non-declarations to this, e.g. template instantiations especially, which should have the fiefdom of where it is instantiated rather than where it is declared, probably.

[Timothee Guerin (timotheeguerin)]

The template instantiation is a good point, I think it would be a different helper but resulting context object would be the same so Declaration is indeed not a good name. I guess LocationContext is ok, just feel quite generic for what Location is

[Timothee Guerin (timotheeguerin)]

Brian Terlson (@bterlson) Nick Guerrera (@nguerrera) could I get rereview of this PR, would like to be able to use that in the linter PR #2066