implement --packages flag

[vsmenon]

From @jmesserly on July 26, 2016 22:31

we need to support package specs :)

Copied from original issue: dart-archive/dev_compiler#607

[vsmenon]

From @jmesserly on July 26, 2016 22:31

FYI to @nex3

[vsmenon]

From @nex3 on July 27, 2016 0:59

Note that if dart-lang/test#414 lands before this is fixed, it'll break dart-lang/test#327.

[jmesserly]

BTW, we seem to be somewhat broken right now due to removal of packages folder (and/or changes to how these resolvers work in Analyzer)

[bwilkerson]

Happy to have a discussion if I can help in any way.

[jmesserly]

What would be really awesome is if there was some API that handled command line options & configuration for the package resolvers (and even more awesome, Dart SDK resolvers).

at one point I had tried https://codereview.chromium.org/2188033002/ but it seemed unclear what semantics to implement given that DDC is a modular compiler without an "entrypoint", and I think my logic was a bit different than analyzer_cli (which itself can be a bit different in "build mode" vs normal mode)

[bwilkerson]

What would be really awesome is if there was some API that handled command line options ...

Agreed. We don't have that today, but should work on it.

... & configuration for the package resolvers (and even more awesome, Dart SDK resolvers).

There is some higher-level API that I can point you to. It isn't stable, so I don't want a lot of users, but it might make your life easier. Happy to talk off-line.

[jmesserly]

@vsmenon were you looking into a similar issue?

[vsmenon]

yes, need to get back to it. :-)

what breakage are you seeing?

[jmesserly]

$ dartdevc -o ~/tmp/test.js --library-root=$HOME/scratch ~/scratch/test.dart
We're sorry, you've found a bug in our compiler.
You can report this bug at:
    https://github.com/dart-lang/sdk/issues/labels/area-dev-compiler
Please include the information below in your report, along with
any other information that may help us track it down. Thanks!
    dartdevc arguments: --dart-sdk=/Users/jmesserly/src/dart/sdk/out/ReleaseX64/dart-sdk -o /Users/jmesserly/tmp/test.js --library-root=/Users/jmesserly/scratch /Users/jmesserly/scratch/test.dart
    dart --version: 1.20.0-edge.3647e7bac036d1a4fb2ed7a70a2e1c2abeb0b31b (Tue Sep 27 15:32:45 2016) on "macos_x64"
FileSystemException(path=packages/; message=Directory listing failed)
#0      _PhysicalFolder.getChildren (package:analyzer/file_system/physical_file_system.dart:274)
#1      ContextBuilder.getPackagesFromFolder (package:analyzer/src/context/builder.dart:391)
#2      ContextBuilder.createPackageMap (package:analyzer/src/context/builder.dart:191)
#3      createFileResolvers.packageResolver (package:dev_compiler/src/analyzer/context.dart:147)
#4      createFileResolvers (package:dev_compiler/src/analyzer/context.dart:154)
#5      createSourceFactory (package:dev_compiler/src/analyzer/context.dart:135)
#6      ModuleCompiler.ModuleCompiler (package:dev_compiler/src/compiler/compiler.dart:85)
#7      _compile (package:dev_compiler/src/compiler/command.dart:86)
#8      compile (package:dev_compiler/src/compiler/command.dart:51)
#9      main.<main_async_body> (file:///Users/jmesserly/src/dart/sdk/pkg/dev_compiler/bin/dartdevc.dart:51)
#10     Future.Future.microtask.<anonymous closure> (dart:async/future.dart:144)
#11     _microtaskLoop (dart:async/schedule_microtask.dart:41)
#12     _startMicrotaskLoop (dart:async/schedule_microtask.dart:50)
#13     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:96)
#14     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:149)

[jmesserly]

the folder I was standing in does not have a ".packages" or a "packages/"

[jmesserly]

basically it seems like we crash without "packages/", which is going away and we don't support ".packages" ... seems problematic :)

[vsmenon]

The crash part should be fixed as part of this CL:

https://codereview.chromium.org/2371113004/

Our tests appear to seamlessly pick up .packages now as well.

[vsmenon]

Note, this should be done as part of #27511 - closing this in favor of that.