New Hooks for Unlocked Packages

[ChuckJonas]

Is your feature request related to a problem? Please describe.
In order to provide enhanced dev-ops around the creation of packages and package versions, it would be helpful to have some additional hooks types.

What are you trying to do
Some examples of what could be done:

• hook on prepackageversioncreate that ensures there are no uncommitted changes
• hook on prepackageversioncreate that runs prettier / linter / static analysis
• hook on postpackageversioncreate that tags your repo with the version of the new package (or creates a new release in github)
• hook on postpackageversioncreate that updates a section in the README with a link to the latest install URL

Describe the solution you'd like
Add the following CLI hooks:

• prepackageversioncreate
• postpackageversioncreate
• prepackagepromte
• postpackagepromote

Describe alternatives you've considered
You can write a new CLI plugin command that "wraps" these calls and handles the results, but that more work and less composable

[AllanOricil]

If the packages were just npm or yarn packages, it would make everything easier.

[ChuckJonas]

@AllanOricil
that would be great... but salesforce would need a full blown module/import system to deal with dependencies. And still, that only even makes sense really in the context of apex metadata.

[AllanOricil]

Is your feature request related to a problem? Please describe.
In order to provide enhanced dev-ops around the creation of packages and package versions, it would be helpful to have some additional hooks types.

What are you trying to do
Some examples of what could be done:

• hook on prepackageversioncreate that ensures there are no uncommitted changes
• hook on prepackageversioncreate that runs prettier / linter / static analysis
• hook on postpackageversioncreate that tags your repo with the version of the new package (or creates a new release in github)
• hook on postpackageversioncreate that updates a section in the README with a link to the latest install URL

Describe the solution you'd like
Add the following CLI hooks:

• prepackageversioncreate
• postpackageversioncreate
• prepackagepromte
• postpackagepromote

Describe alternatives you've considered
You can write a new CLI plugin command that "wraps" these calls and handles the results, but that more work and less composable

@ChuckJonas
I think you could make those hooks to run on your Git. Like, before creating a version you always run lint, prettier and static analysis. You make those automations to run on a PR to a Dev branch. If those automations ran well you approve the merge to Dev. This way you don't relly on the dev to add the scripts in the hooks. Imagine everyone doing that over and over again to each package you create. It is not good.

[msrivastav13]

In Sample gallery apps (https://github.com/trailheadapps/easy-spaces-lwc/blob/develop/.github/workflows/packaging-sfdx-ci-develop.yml) we do 2 and 4 today using github actions today!

I agree will make it vendor-agnostic if CLI provides hooks.

Also, it is not a bad idea to use the OCLIF hooks. Since the sfdx cli is build on the OCLIF, I think these hooks should work in CLI as well

https://oclif.io/docs/hooks#lifecycle-events

[ImJohnMDaniel]

@msrivastav13 -- I didn't think that OCLIF hooks were possible yet.

The last time that I spoke with @clairebianchi and @amphro about this, they were saying that a lot of rework was needed to the internals of the existing CLI code in order to correctly support OCLIF hooks.

Is that still the case?

[msrivastav13]

I will wait for @clairebianchi and @amphro to officially confirm on this :)

It is in the docs at least for now. I am going to try it now :)

https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_plugins.meta/sfdx_cli_plugins/cli_plugins_customize_hooks.htm

[ChuckJonas]

@AllanOricil

I think you could make those hooks to run on your Git. Like, before creating a version you always run lint, prettier and static analysis. You make those automations to run on a PR to a Dev branch. If those automations ran well you approve the merge to Dev. This way you don't really on the dev to add the scripts in the hooks. Imagine everyone doing that over and over again to each package you create. It is not good.

Didn't say anything about running these hooks via local dev machines. I envisioned these running in a CI running sfdx... And ya, you can already all this via build script, but this could make it easier to setup, more standardized and upgradable across multiple repos.

[msrivastav13]

@ImJohnMDaniel and @ChuckJonas I was able to validate that oclif lifecycle hooks fire on all commands (standard OOB commands) once you add them to a custom CLI plugin.

Here is a sample project that shows this in case you are interested.

https://github.com/msrivastav13/oclifhookssfcli/tree/master/src/hooks/oclifhook

The Key is you add the hooks to the package.json

https://github.com/msrivastav13/oclifhookssfcli/blob/06cd110929b6495df0524ac4b7f8a52a852ffee0/package.json#L47

[ImJohnMDaniel]

Yes I agree that they work in custom plugins that are expecting the hook. My point was that I thought that the current CLI functionality does not currently work with hooks. That is where we need the ability to tie in the hooks.

[msrivastav13]

Ah got your point @ImJohnMDaniel ! Actually that's not true. You create the hooks via a custom CLI plugin but once you have them they work on any command out of the box provided by salesforce CLIand can listen for all OCLIF lifecycle hooks. Just tested it.

[ImJohnMDaniel]

Good to hear.

[AllanOricil]

@AllanOricil

I think you could make those hooks to run on your Git. Like, before creating a version you always run lint, prettier and static analysis. You make those automations to run on a PR to a Dev branch. If those automations ran well you approve the merge to Dev. This way you don't really on the dev to add the scripts in the hooks. Imagine everyone doing that over and over again to each package you create. It is not good.

Didn't say anything about running these hooks via local dev machines. I envisioned these running in a CI running sfdx... And ya, you can already all this via build script, but this could make it easier to setup, more standardized and upgradable across multiple repos.

@ChuckJonas could you explain what are you planning? Because usually we run those automations in Git, not per package. Because developers often forget to configure or run it, and also because those actions are generic and has to run for every package. Hooks were created to automate steps that are specific for a particular package. If an action has to ran on every package, always focus on automating on your Git remote repository, where you gather all the code.
Imagine your project with 100 packages and each one of them configured to run "lint, prettier and static analysis", and now imagine somebody forgot to add the script on the package.json and configure the hook.

[ChuckJonas]

@AllanOricil

As I stated above, I would be running these hooks from a git CI for the release management of the packages themselves. The examples I listed are just easy to talk about scenario's. There are countless use-cases, I just spit off the first couple that came to my head.

Because usually we run those automations in Git, not per package.

All the unlocked packages we use live in their own git repo.... So both per git repo and per package.

Hooks were created to automate steps that are specific for a particular package.

There are no hooks for packages yet... that's what this issue is requesting.

Imagine your project with 100 packages and each one of them configured to run "lint, prettier and static analysis", and now imagine somebody forgot to add the script on the package.json and configure the hook.

We're not using packages like that. We are using packages to share general purpose code across many completely unrelated orgs.

EG:
https://github.com/callawaycloud/Salesforce-Environment-Vars
https://github.com/callawaycloud/apex-rest-route