Pub: Should we expose static configuration to control which JS compiler to use?

[jakemac53]

Static configuration has some benefits:

• you don't have to type --compiler=dartdevc whenever you start pub serve
• editors like intellij that start up pub serve on their own can use the static config

This also introduces potentially yet another configuration file, or additional overhead into the pubspec.yaml which isn't really relevant to the package (only how it is developed locally).

[jakemac53]

cc @munificent @nex3 @devoncarew @jwren

[jakemac53]

My original proposal called for a new compiler field in the pubspec.yaml, which would accept either just a String (name of compiler to use for all modes), or a Map<String, String> of mode to compiler to use.

There was some pushback because developers might accidentally end up using dartdevc for pub build and releasing that way. @devoncarew suggested we could mitigate that by adding a warning in pub build if using dartdevc.

[munificent]

Repeating what I told Jake in person...

I don't think this belongs in the pubspec. The pubspec exists to store persistent state about the package itself, and not user or workflow-specific details about how they hack on it. For example, we don't put things like Sublime preferences in there, or whether or not the user prefers colored output from pub.

There is a valid argument that the compiler being used is a fundamental part of the package and that all people hacking on the package should use the same compiler. It's analogous to, say, putting the optimization level in a Makefile for a C project.

That's true, but I think the end goal of this is that DDC will be the default compiler for debug web builds. Given that, making users add a field to their pubspec to enable it now will end up being pointless boilerplate -- eventually every single user would be expected to have it.

Passing --compiler=dartdevc is a (hopefully) temporary measure to let users start using it before we're ready to fully canonicalize it and make it the default. I don't want to enshrine that in pubspecs since pubspecs are forever.

[devoncarew]

We'd have to build UI in IntelliJ - a product w/ ~4 month release cycles - for a cli flag which is a temporary measure. I think we'd like to avoid that, which is why a static config option is preferable to us. It would be nice if the mechanism that pub serve was using - dart2js vs ddc - was transparent to the run/debug UI (that the mechanism pub serve uses to compile can change under the covers, but the run / debug UI stay the same).

@alexander-doroshko, is there a way to pass flags or env vars to the pub serve process during a launch? Could we have a field in the launch config UI for arbitrary cli flags to pub serve? This would mean that we wouldn't have a specific (and temporary) use DDC checkbox.

[jwren]

I'm not saying that it should be in the pubspec, but by not putting it with the pubspec (or somewhere else on disk), it forces our hand to put an option in (all) the IDEs that support Dart.

As Jake mentioned to me, there will potentially be lots of options and settings as time goes on. Have everyone on a team required to go configure their IDE to be in sync with each other as time goes on is not a great UX.

As for pubspecs living forever, I don't think this should be a deterrent: Dart source has migrated through many variations, most recently to strong mode. Lots of lines of code have been update to do this, users get errors from the analysis server, they update their dart they check in their code. Removing --compiler-dartdevc would be a trivial change for users.

[jwren]

@devoncarew Correct. The checkbox would not be in a launch configuration. Currently the pub serve (@alexander-doroshko please correct me here if this is incorrect), is managed as a service, not the launch configuration. This means that the setting would probably be a project specific setting in the Dart settings dialog.

Not the end of the world, but I come back to the teams argument: if this is one of potentially many settings on a project, then it should be stored on disk via the VCS.

[alexander-doroshko]

Yep, in IntelliJ we'll need to add either a 'Use DDC' check box or a 'Pub Serve parameters' field. It will have to be per project, not per run configuration.

[natebosch]

We've discussed that we might need other configuration for DDC, things like entrypoints. I can see value in a ddc.yaml for config, and we might even use it's presence to act like --compiler=dartdevc

[munificent]

As for pubspecs living forever, I don't think this should be a deterrent: Dart source has migrated through many variations, most recently to strong mode.

The reason they are able to do this is because we have a package manager with a strong versioning story, so that developers can evolve their code without affecting users of previous versions of the same package. That system exists because pub itself and the metadata users author to describe packages does not change. The latest version of pub today can successfully read and consume a pubspec that was published several years ago, and does on a regular basis.

Pubspecs are forever so that code doesn't have to be.

I'd be up for maybe pulling the flag from an environment variable as well as the command line if that makes things easier, but it doesn't feel right to me to put it in the pubspec.

[devoncarew]

Perhaps a way to think about this is that the use of dart2js vs ddc should be a project level choice, like compiler optimization flags (mentioned by Bob above). So, a project might opt into development w/ DDC for pub serve, and deployment via dart2js (via pub build).

I have a use case myself for a project where I'd like the pub build output to be created via DDC (instead of dart2js), and I'd like this to be consistent for all people working on the project.

[jakemac53]

Closing this as we had some offline discussions and came to a decision.

We will be adding a js_compiler top level key to the pubspec.yaml file. The keys under that will be mode names, and the value is the compiler to use for that mode.

Example:

js_compiler:
  debug: dartdevc
  release: dart2js

Any mode not specified will get the default, which today is dart2js for all modes. Likely at some point in the future dartdevc will become the default in the debug mode.