Feature: tspconfig project with entrypoint#10548
Feature: tspconfig project with entrypoint#10548timotheeguerin wants to merge 10 commits intomicrosoft:mainfrom
Conversation
microsoft-github-policy-service
Bot
added
the
compiler:core
commit: |
|
All changed packages have been documented.
Show changes
|
|
You can try these changes here
|
timotheeguerin
requested review from
AlitzelMendez,
RodgeFu,
bterlson,
chrisradek,
markcowl and
witemple-msft
as code owners
markcowl
left a comment
markcowl
left a comment
There was a problem hiding this comment.
Does this mean we should eventually change the structure of azure-rest-api-specs typespec projects?
The behavior here is that, if there is a project tspconfig.yaml in the path ancestors of the command line path, the config entrypoint will always be used. I think this either means that all azure-rest-api-specs configs should not use project configs, or that we need another project config for client customizations in another directory, and TypeSpecValidation will have to be changed accordingly.
Am I getting the behavior wrong, or is this the intention?
| } | ||
|
|
||
| // Validate project-specific constraints | ||
| if (data.kind === "project" && getBaseFileName(filename) !== TypeSpecConfigFilename) { |
There was a problem hiding this comment.
Is this just defense in depth? what is the context in which we could be loading config and it's not from a tspconfig file, since we are already checking that --config provided config cannot be project config?
There was a problem hiding this comment.
yeah didn't think that it probably doesn't seem possible via compile but might be via ide(you open a tspconfig.foo.yaml with kind: project)
| message: `project tspconfig found in ${dir}, entrypoint: ${entrypoint}`, | ||
| }); | ||
| // Project boundary found — stop walking regardless of whether entrypoint exists | ||
| return candidate ?? (isFilePath ? path : undefined); |
There was a problem hiding this comment.
Isn't this going to override a passed-in entryPoint path? It seems like the command line entry point should override config settings.
There was a problem hiding this comment.
hhm yeah good point
There was a problem hiding this comment.
and I bevlive this is the source of your other comment. It would be I think the plan that we add that for every project in azure rest api specs repo but not sure I see it as a requirement yet.
tsp compile should always respect that path. If it points to a tsp file, it MUST be the entrypoint. if it points to a folder then we try but only in that folder (no walk up)
tspconfig proejct->entrypointpackage.json->tspmain/exports./main.tsp
which means in specs repo we should be fine having the same structure just with added
kind: project
entrypoint: ./main.tsp # if we want to be explicittsp compile ./specification/foo/bar # compiles main.tsp
tsp compile ./specific/foo/bar/client.tsp # compile client.tspThere was a problem hiding this comment.
and actually this is fine, the behavior in this file is just for LSP, we use a different logic for tsp compile
…ture/project-config
3 participants
No description provided.