-
Notifications
You must be signed in to change notification settings - Fork 230
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
[Proposal] Local hooks for pub publish
validations
#4058
Comments
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 It makes some sense for For I don't think it makes sense to have hooks for |
Btw. the hook for |
I think we can narrow the scope of this issue to be just hooks for |
pub publish
validations
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 the
bin/
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.
The text was updated successfully, but these errors were encountered: