Deprecate & discontinue package

[mit-mit]

With support for creating projects with dart create, we should deprecate this package:

Prep work:

• [x] Update Dart IntelliJ to call dart create
• [x] Update VS Code to call dart create
• [x] Move the templates from here to https://github.com/dart-lang/sdk/tree/master/pkg/dartdev
• [x] Change dart create to use the template directory, and remove dependency on stagehand

Finalization work:

• [x] Add deprecation warning to the output of the present command
• [x] Mark this package discontinued on pub
• [x] Move this repo to the dart archive

[devoncarew]

An update - I believe that the dart create functionality has existed since Dart 2.10. We should confirm the version, but in any case IDEs can now move over to using dart create in preference to pub global activate stagehand after they've done an min. SDK version check.

[devoncarew]

@jwren - can you create a tracking issue for the Dart IntelliJ plugin?

@DanTup - similarly for VS Code; thanks!

[DanTup]

@devoncarew @mit-mit is there an existing way we can get the template list in a parsable format? Right now we're using pub global run stagehand --machine which gives us JSON and we use to populate the selection of templates.

[devoncarew]

dart create --list-templates :)

[DanTup]

I've gated this on SDK version 2.13.0-0. Please let me know if that's not correct and I should change it.

I presume the deprecation notices being printed here won't apply to --machine, so we'll still get clean JSON for people on <= v2.12 SDKs?

[devoncarew]

Thanks!

I've gated this on SDK version 2.13.0-0. Please let me know if that's not correct and I should change it.

I think all the support we need in the dart command has existed since 2.10.0.

[mit-mit]

I think all the support we need in the dart command has existed since 2.10.0.

Yup, I'm pretty sure too: https://medium.com/dartlang/announcing-dart-2-10-350823952bd5

[DanTup]

Ah, great! I misunderstood from the action about moving templates here and Devon's recent commit that all the templates weren't here, but I see now they were just previously being read out of out the Stagehand project. I'll lower the check to 2.10 and will merge into the upcoming Dart-Code release then. Thanks!

[devoncarew]

wrt Add deprecation warning to the output of the present command (from above), we'll want to make sure to not emit that when the --machine flag is passed, as IDE parse the output of that command (or, perhaps do something like emit the deprecation message to stderr - IDEs parse stdout).

@bkonyi - once the IDE work is complete and we've shipped releases that call out to dart create - can you drive the remaining portions of this issue?

[jwren]

The YouTrack issue is at https://youtrack.jetbrains.com/issue/WEB-45841. Alex or myself will take care of it soon.

[bkonyi]

@bkonyi - once the IDE work is complete and we've shipped releases that call out to dart create - can you drive the remaining portions of this issue?

@devoncarew sure, sounds good to me.

[alexander-doroshko]

Hi, I'm updating the Dart plugin for IntelliJ IDEA to use dart create instead of stagehand and I have a couple of questions.

• Both stagehand and dart create name the project after the folder name. But stagehand normalizes the name to make sure that it's a valid Dart identifier. Do you think dart create should do the same? Example: run stagehand in foo-bar folder, it will write name: foo_bar to the pubspec.
• Assume I've created an empty folder, switched to it and run dart create --force .; the tool generates name: . in the pubspec.yaml. Wouldn't it be more intuitive to take the project name from the enclosing folder (normalized as per previous comment)?

[DanTup]

I hit the same issue using --force . in VS Code. I thought I was just doing things strangely (we create the folder up-front because of how we trigger running the command in the new workspace after opening it), so I changed it to execute in the parent folder and then use the foldername instead of ..

I think it'd be good to support ., but even if it's changed now, for compatibility with SDKs v2.10 - v2.12 I think you'd need to avoid the . anyway.

[bkonyi]

This CL should address the dart create --force . case and also prevent users from creating projects with invalid package names (also see https://github.com/dart-lang/sdk/issues/43216).

[alexander-doroshko]

address the dart create --force . case

Thanks!

prevent users from creating projects with invalid package names

As I understand, it prints an error message and exits. IntelliJ's project wizard doesn't have any restrictions regarding project folder naming, so this will result in an empty project instead of a Dart project template.

Will you consider normalizing project name instead of failing (this was the behavior of stagehand)?

Alternatively, can there be a flag for the project name, so that the folder name doesn't matter at all?

[bkonyi]

prevent users from creating projects with invalid package names

As I understand, it prints an error message and exits. IntelliJ's project wizard doesn't have any restrictions regarding project folder naming, so this will result in an empty project instead of a Dart project template.

Will you consider normalizing project name instead of failing (this was the behavior of stagehand)?

Ah sorry, I missed that bit. I've updated the CL to perform the same normalization as stagehand (e.g.,- to _ and foo.dart to foo).

[devoncarew]

@bkonyi - the IntelliJ work has now landed. I think we can start on the next stage of deprecation (the other steps above). I'm not sure of the best timing for that; perhaps sometime after we release the next stable (give people and tools time to update to the latest versions)?

[GZGavinZhao]

dart create drops some templates like web-angular, which would be really nice if we can still have those options