The convention for the bin/tool scripts is poorly explained about grinder.dart HOT 13 CLOSED

I understand your opinion.

But we normally run tests by doing below..
cd test -> find a dart file that have main function.

So.. we can run dart test/all.dart. that's all.

updated: sorry I wrongly understand this issue.

from grinder.dart.

I would like to use pub run because it will run transformers. pub run grinder tests was just an example.

from grinder.dart.

We had been relying on a user-supplied script at the root of the project - grind.sh - which just delegated to tool/grind.dart. With the new pub global activate feature, we moved to installing bin/grind.dart and bin/grinder.dart on the user path, which delegate to the host project's tool/grind.dart and tool/grinder.dart scripts, respectively.

We could definitely use better docs about this though! Patches welcome :)

Some ways to run grinder currently:

• pub global run grind tests
• pub global activate grinder, then grind tests
• dart tools/grind.dart tests

from grinder.dart.

So for some clarification, the build configuration should live in tools/grinder.dart or tools/grind.dart? Ultimately what I did, which works, is define my build (tasks, etc) in tools/grinder.dart and run pub run grinder:grinder tests. It is my understanding that this executes packages/grinder/bin/grinder.dart, which is finding my build config in tools/grinder.dart.

I will be happy to create a pull request once I have an understanding of how everything should work. I think the first thing to clarify is where the app's build configuration should live, and then the easiest way to run it via pub run.

from grinder.dart.

Yup, all the above sounds right. But, to re-state it:

• user build scripts go in tool/grind.dart (or tool/grinder.dart)
• the user needs to execute pub global activate ginder once - this downloads grinder and puts the two binaries on the path
• the user can run grind foo or grinder foo (equivalent commands: pub global run grind foo / pub global run grinder foo)
• the grinder command grind will look for and execute tool/grind.dart in the user's project; the grinder command will look for and execute tool/grinder.dart

Which all sounds a bit complicated, but the end goal is that the user can type grind foo in the root of their project, and have it execute the foo task in their build script.

from grinder.dart.

I'd love to have a single way to run the tool, and a single convention for the script name. Since the tool's repo is named grinder.dart, I'd vote for grinder

from grinder.dart.

+1 going down to one entrypoint. We can have a deprecated message print out for a while if you use the other entrypoint.

from grinder.dart.

Agreed. To actually run the tool, id prefer 'grind' just because a verb seems more appropriate. I'm indifferent as to the grind config name.

from grinder.dart.

I'd lean towards grind as well; grinder as the noun and grind as the verb. Plus, all the build scripts I've written have been named grind.

I'll make a change to deprecate bin/grinder.dart.

from grinder.dart.

Cool. I can start on a PR to improve the readme.

from grinder.dart.

grind works for me. Yay for a single way to do it! :)

from grinder.dart.

@devoncarew IMO It's still a bit confusing to have both grinder and grind. In particular it would be nice to use the same name whether using pub run or not, currently it's:

pub run grinder
grind

I prefer grind, but pub run grind would require changing the package name, which would mean deprecating the entire package, so I'd be fine having to run grinder.

from grinder.dart.

Yeah, I have in the past argued that the main executable for a package should have the same name as a package. There's always reasons to do something different (grinder uses grind; dart_style uses format), but there's a lot of value to the users in just knowing what the main executable should be given the package name.

I'll do a bit more noodling on this.

from grinder.dart.