Skip to content
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

Double-exported tasks aren't visible to grinder #337

Open
nex3 opened this issue Jun 9, 2019 · 0 comments
Open

Double-exported tasks aren't visible to grinder #337

nex3 opened this issue Jun 9, 2019 · 0 comments

Comments

@nex3
Copy link
Contributor

nex3 commented Jun 9, 2019

If grind.dart exports a file that defines a task, grinder will see that task. However, if that file in turn exports another file that defines a task, grinder won't see it. This makes it difficult to write libraries that provide tasks that users can include in their grind.dart via export (which is the only means available to do so as far as I know).

For example:

// grind.dart
import 'package:grinder/grinder.dart';

export 'midstream.dart';

main(List<String> args) => grind(args);
// midstream.dart
export 'upstream.dart';
// upstream.dart
import 'package:grinder/grinder.dart';

@Task('Print hello.')
hello() {
  print("hello");
}
@devoncarew devoncarew added this to the project bootstrap milestone Jul 18, 2019
nex3 added a commit to google/dart_cli_pkg that referenced this issue Jul 25, 2019
This has a few benefits:

* It allows us to dynamically choose task dependencies (so for example
  the Linux standalone package can depend on the native executable
  task when running on Linux).

* Similar tasks can be defined programmatically.

* Task names are decoupled from Dart function names, which in turn
  allows us to avoid manually namespacing the package in favor of
  encouraging it to be imported with a Dart namespace.

* It works around google/grinder.dart#337 and google/grinder.dart#338.
nex3 added a commit to google/dart_cli_pkg that referenced this issue Jul 29, 2019
Declare tasks programatically rather than declaratively

This has a few benefits:

* It allows us to dynamically choose task dependencies (so for example
  the Linux standalone package can depend on the native executable
  task when running on Linux).

* Similar tasks can be defined programmatically.

* Task names are decoupled from Dart function names, which in turn
  allows us to avoid manually namespacing the package in favor of
  encouraging it to be imported with a Dart namespace.

* It works around google/grinder.dart#337 and google/grinder.dart#338.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants