Open jonasfj opened 1 year ago
Note: This would have implications that makes it harder SLSA attestations with automated publishing as we'd probably want to run such publish-hook in a non-networked environment.
Just to be clear - you are not suggesting here that dependencies can define hooks that automatically get get executed?
I think this makes a lot of sense for pub publish
such that you can set up your own validations.
It makes some sense for dart test
. Though I think this should really be a feature in package:test....
For pub get
I cannot see any good use-cases. Do you have any?
I don't think it makes sense to have hooks for pub add
, pub upgrade
, pub deps
, pub cache ...
, pub downgrade
, pub token
, global ...
login
, logout
....
Btw. the hook for dart test
is probably an sdk feature - not a pub client feature.
I think we can narrow the scope of this issue to be just hooks for pub publish
.
When running a Dart command like:
dart pub get
dart pub publish
dart test
dart analyze
It'd be really nice if it's possible to do hook into these commands from the root package.
Example: Some packages may have a build or code-generation script that must run before the package is published. It'd be nice if it was possible to make a
hook/publish.dart
script that is invoked bydart pub publish
whenever the command is called.Proposal: Invoke
hook/<command>.dart
fromdart <command>
The proposal is fairly simple, we invoke
hook/<command>.dart
fromdart <command>
. Perhaps we limit this to select commands, so that not all commands can be hooked, for example:dart test
would invokehook/test.dart
which could be used to:package:test
dart pub publish
would invokehook/publish.dart
which could be used to:Alternatives:
dart run :<command>
ortool/
Today the
tool/
folder is codified as something to be used for scripts used during development. Of course, that means you have to remember to use those tools. Having hooks that are automatically called, might be easier to remember and it might make it easier for other team members to remember to invoke these tools.Creating a
tool/publish.dart
which does a build process and then callsdart pub publish
is not a bad idea, but there is some risk that you or a teammate will forget about it and calldart pub publish
directly instead.Another alternative option today is to write commands in
bin/<command>.dart
and call these usingdart run :<command>
this have the same downside astool/
(namely you have to remember to use it). Butdart run
will take care to fetch dependencies and such. However, if you are publishing a package then thebin/
commands will also be available to people consuming your package, and this might not be desirable (especially for pre-publish build script).Please upvote this issue, if you think this is a useful feature.
I think it's reasonable to be concerned that this quickly gets too complicated, and that it becomes hard to reason about what a command does when developing locally.