Migrate to use as dev dep and `dart run`

[mit-mit]

We should migrate webdev to use dart install instead of dart pub global activate. The new install command should make webdev faster (it does an AOT compile), and we'd like to deprecate dart pub global activate.

I tried simply switching things over, but it looks like tests fail.

There's also an issue here: #2758

[mit-mit]

cc @kevmoo

[dcharkes]

What is the typical way to run webdev?

1. Executable placed on PATH: webdev <...>
2. Last published version from pub, evergreen: dart run webdev@
3. A version selected via the pubspec dev dependencies and possibly pinned via a pubspec lock: dart run webdev

I feel like you'd want to pin webdev as a dev dependency (option 3)? In that case, you'd never dart install it. But maybe I'm not very aware of typical user journey of devs using webdev.

[mit-mit]

Today it's a global activate: https://dart.dev/tools/webdev#installing-and-updating-webdev

But I don't know enough of the history as to why that as (as opposed to say the dev dependency + dart run webdev). Maybe @kevmoo or @sigmundch can shed some light?

[jakemac53]

I can't remember for sure, but one reason to keep it as a globally activated/installed packages is that webdev has a LOT of dependencies. If we told people to depend on it as a dev dependency, those would become a part of their packages version solve and it would likely increase the possibility of incompatible version constraints quite a bit. It also would increase the urgency around widening dependency constraints when breaking versions of the various deps are released, where today we can do that at our own leisure as there is little to no impact to consumers of the package if we are on some old versions of deps.

[sigmundch]

cc @natebiggs

If I remember correctly, another constraint was the tight coupling webdev has with the SDK. Some internal dependencies, like dwds/vmservice, are co-developed with SDK changes and often force us to update them in lockstep.

Webdev still asks for dev dependencies from users on the build-runner/build-web-compiler packages, though. Those have much a more stable evolution story and a clear contract with the rest of webdev.

[biggs0125]

IIRC there was an issue with dart install around getting access to the SDK files. When webdev is serving dev code it tries to pull assets out of the SDK. When it's running in AOT mode I think we don't have a well-defined SDK location so webdev doesn't know where to get those assets.

I'm not sure how dependent webdev itself is on a specific version of the SDK. But I think there might be some dependency on DWDS which is itself dependent on the internals of the SDK.

[kevmoo]

Yep! I have a bunch of code that uses Platform.resolvedExecutable that now...doesn't work.

Tracking issue: dart-lang/sdk#63210

[mit-mit]

When webdev is serving dev code it tries to pull assets out of the SDK

I think this suggests that webdev really isn't an executable; I'd expect those to be self-contained.

Would it make sence to make webdev a dev dependency package, and then just rely on developers dart run'ing it?

[jakemac53]

Would it make sence to make webdev a dev dependency package, and then just rely on developers dart run'ing it?

There is nothing preventing this, but it also should not be necessary, and the fact that it even works is completely accidental. It works because dart run runs by compiling to kernel ran on the VM and not an AOT executable. That has absolutely nothing to do with it being a dev dependency versus globally installed executable.

The core issue here is that dart install forces a specific compilation mode + runtime which does not support all the core libraries (and I am not just talking about mirrors). You should be able to choose, as a package author, which compilation modes you support and do not support, and ideally also a default compilation mode and runtime when you are dart install'd.

All of these issues stem from the lack of that feature, and I don't believe we should completely change how we expect users to interact with our tools because of it. As far as I am aware, while the downsides are not catastrophic by any means, using webdev as a dev dependency is strictly worse. There is no benefit to doing it this way at all. It is a workaround for a breaking change that just isn't necessary.

A hello world project with only webdev, build_runner, and build_web_compilers has 122 transitive dependencies, 2 of which are currently outdated (one by multiple versions). This is not a good recipe for success. Some of this is build_runner and build_web_compilers fault (you get 90 just with those), but these could be made entirely optional by migrating to frontend server.

I think this suggests that webdev really isn't an executable; I'd expect those to be self-contained.

It isn't a completely self-contained executable. But it very much is an executable (it has a main). There are all kinds of executables that have additional requirements/dependencies outside of their own binary. When doing Android development for example, many tools require ANDROID_HOME and other environment variables in order to find the Android SDK and other tools.

The alternative is basically to say "any tool which uses the Dart SDK must be shipped with the Dart SDK". This is the obvious way to get the fully self contained property. Putting aside the fact that this is only even possible for Dart owned tools, the end result of this approach would just be a bloated SDK, dramatically reduced velocity for all of those tools, more difficulty in rolling out breaking changes to any of those 122 dependencies, and a reduced capacity for breaking changes in webdev due to them being "all or nothing". The impact on users of breaking changes is far worse in this model because a breaking change in webdev can prevent users from updating their SDK, they are now tightly coupled in an undesirable way.

Because of this, it is my opinion that the SDK should be as minimal as possible, and any tool which does not have to ship with the SDK should not ship with the SDK. That includes webdev, and imo many of the other tools that are currently developed and shipped with the SDK. Not necessarily a popular opinion but I stand by it.

It is worth remembering that these tools were very explicitly removed from the SDK in Dart 2.0, and I think for good reason. From a user perspective especially, I think this was the correct choice.

[biggs0125]

@mit-mit Is this really a P1 or can we lower the priority here to P2?