-
Notifications
You must be signed in to change notification settings - Fork 243
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Init redesign #6045
base: main
Are you sure you want to change the base?
Init redesign #6045
Conversation
You can try these changes here
|
@@ -198,7 +198,6 @@ export async function createTypeSpecProject( | |||
const initTemplateConfig: InitProjectConfig = { | |||
template: info.template!, | |||
directory: selectedRootFolder, | |||
folderName: folderName, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we keep the folderName here (just remove the explicit InitProjectConfig type at line 198) so that it will still be compatible with the existing compilers which expecting the folderName property?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hhm I see, i think this is not done as it should in the vscode extension. The scaffolding logic should be included in the extension. This means you need to already have the compiler installed which defeat half the point of the init template.
There is no reason to keep supporting older compiler with older init engines, this just adds extra friction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't want to duplicate and maintain the same logic of init in vscode (and other IDEs) again. Instead vscode would prompt to install tsp compiler when creating project if needed and then work with it to do the init.
(I actually looked into whether it's possible to import these init functions directly, but found it needs to change init code a lot which is coupled with other compiler code closely. I would be happy to do the change if you have any good idea there for the import. :))
There is no reason to keep supporting older compiler with older init engines, this just adds extra friction.
yeah in general, but I think it's still better to make it compatible when it's easy to do though it's not required in preview. But anyway, it's not a blocker here, I can make the change in vscode's PR (or continue the discussion) later. thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let me try to do some basic thing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah there is definitely some significant change to do for this to work but I still think this is the right way to go, the current experience is not ideal.
Have this pr that does the first step #6086
Its now failing to write anything with some weird permission error, I don't think I have time to investigate a lot more right now not is this super urgent though the current approach is also be broken with the standalone TypeSpec version
Co-authored-by: Crystal Barragan <cbarragan@microsoft.com>
Co-authored-by: Crystal Barragan <cbarragan@microsoft.com>
Co-authored-by: Crystal Barragan <cbarragan@microsoft.com>
fix #5876
fix #5859
Non empty folder confirmation
Template selection
Installaling dependencies
Completed
Interupted