feat: Run scripts from pubspec.yaml?

[jolexxa]

Tools like derry let you add a scripts to your pubspec.yaml file, like so:

scripts:
  build: flutter pub run build_runner build --delete-conflicting-outputs

And, if you've done dart pub global activate derry you can run derry build in your project's folder to run the above command. I think being able to store scripts inside the pubspec.yaml file is a convenient and easily discoverable way for newcomers to see what commands are available, kind of like the "scripts" section of a package.json, but that might just be the web developer in me.

I am proposing that we take the script commands in the readme.md that's generated for each project and add them to the pubspec.yaml (or another file or scripts folder perhaps?) and encourage the use of a script runner (or build one into very good cli) so that script commands are not just discoverable, but easily accessible. It's a minor thing, but it crossed my mind again so here's a ticket.

[alestiago]

I think this is a very cool suggestion!

Having something like very_good run dev for flutter run --flavor development --target lib/main_development.dart, would be cool.

[jolexxa]

@alestiago IIRC you have a branch that does this — would you consider uploading a PR and mentioning this issue so we can get additional 👀?

[alestiago]

@definitelyokay just quickly published the branch with the code. I'm missing tests and refactoring, is purely a proof of concept. The branch can be found here. For the time being I'm not thinking on uploading a PR since it was designed as a proof of concept and requires some work.

Proof of Concept GIF

In order to run locally you need to do some trickery. I did this some weeks ago and I forgot how to already. But if I try to recall as hard as I can you require to bump the version in the pubspec.yaml and also use dart pub global activate -s path . within the CLI repo.

Then you can add a scripts.yaml as the following and define all the commands you wish. If this is not found then it looks within the pubspec.yaml for a script tag (you can also define them there). The rational behind this was so I could ignore scripts.yaml file whenever I require pubspec.yaml updates.

Example scripts.yaml

scripts:
  - build: "echo hello"
  - friend: echo friend
  - multi:
    - echo hello
    - echo world
  - deploy: dart pub global activate -s path .
  

I did run into the same issue that @frencojobs commented in the "Why and How" section of Derry's README.md

Since Dart's Process isn't good at executing system commands, I used Rust with the help of Foreign Function Interfaces

Having said this, in that branch I'm only using "Dart's Processes", so something more sophisticated might be required.

[fabiancrx]

Is this a better alternative than for example just generating a makefile? Using a makefile would not be reinventing the wheel and they're very common in Unix systems. One downside would be for windows users would might have to install additional software.

Then one could just to

make staging and forget about the long tail boilerplate when developing

Example makefile

.PHONY: build-runner
build-runner:
	flutter  pub pub run build_runner build --delete-conflicting-outputs

.PHONY: watch
watch:
	flutter  pub pub run build_runner watch --delete-conflicting-outputs

.PHONY: unit-test
unit-test:
	flutter test --coverage --coverage-path=./coverage/lcov.info

.PHONY: staging
staging:
	flutter run --flavor staging --target lib/main_staging.dart

.PHONY: production
production:
	flutter run --flavor production --target lib/main_production.dart

[felangel]

Looks like @rodydavis just implemented this https://twitter.com/rodydavis/status/1543388974424551424?s=21&t=Mvh6iL4YvU0mxe54GjdwNA

[felangel]

See https://pub.dev/packages/flutter_scripts

[jolexxa]

@felangel Perhaps we could leverage that package to run scripts from very_good cli? Having all of this functionality in one place would be incredibly convenient (hence all these issues).

[rodydavis]

Feel free to use any code and port it to the cli!

[felangel]

After discussing with the team we've decided to close this as "won't fix" because:

• This is functionality that is currently available package:flutter_scripts
  • We'd prefer not to wrap flutter_scripts because it introduces another dependency in very_good_cli for little gain
  • We'd prefer not to copy the functionality into very_good_cli because it doesn't provide additional value on top of what flutter_scripts already offers.

Sorry for any inconvenience!