I don't use Husky and don't have much knowledge about it, all I know is that below is what the npm lock file update runs. This flag was created to sync the lock file and that's all it should do. I added this flag to replace the previous and often failing implementation that tried to modify the lock file directly, the new sync flag is simply calling whichever package manager is installed to do the synching of the lock file (we should always rely on the package manager instead of trying to modify the lock file ourselves which is a bad idea). It does accept extra npm arguments if that helps.

Looking at the Version command, the sync seems to happen before the version and postversion lifecycles.

Then the version lifecycle is called later at line 838 and the postversion lifecycle is at line 860. The order of the lifecycle for the lock file is exactly the same as the original Lerna when it tried to update the lock file directly. From what I can remember, the lock file must be updated before being added to the list of git changes and so before the version lifecycle

So I don't know what your problem is since I don't use that kind of scripts on my side and I can't provide much more info. The only suggestion I could give is to look at the available version Lifecycle Scripts and maybe use a different one if that helps, otherwise I have no idea. Another suggestion might be to change the logs to verbose and see what commands it runs, and also maybe try it via the --dry-run mode which might help to see what runs.

in my case I don't need to use this sync flag because I use the workspace: protocol which technically speaking never changes the lock file neither git changes because workspace: are only replaced at publish time. However that is not true for npm and that is why this sync flag was created. I know the Jest project use this flag with Lerna-Lite but they also switched to workspace: not long after so they probably don't need the flag either.

EDIT

Actually someone did install Husky for conventional commits checks in one of my project and I also had to set HUSKY: 0 because it failed without it but that's all I did and it all worked correctly after. Note that I use dynamic Lerna version command because I have a checkbox in my release to sometime test it in dry-run mode and I build the Lerna query dynamically

(ref release.yml)

- name: Lerna Version 🏷️
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
          NPM_CONFIG_PROVENANCE: true
          HUSKY: 0
        run: |
          git config --global user.name "${{ github.actor }}"
          git config --global user.email "${{ github.actor }}@users.noreply.github.com"
          pnpm whoami
          pnpm exec ${{ env.LERNA_VERSION_QUERY }}

Hi @ghiscoding many thanks for your quick and detailed response!

I investigated a little bit and basically the problem is that npm install --package-lock-only runs all the npm hooks, so setting "syncWorkspaceLock: true" was causing husky to be initialised, because HUSKY env var was already out of scope when this command run.
Leaving "syncWorkspaceLock: false" doesn't run npm install --package-lock-only so there is no problem.

I bypassed the issue moving HUSKY env var in the parent scope and now even setting "syncWorkspaceLock: true", when Lerna runs npm install --package-lock-only the HUSKY var is set and Husky is not initialised.

Anyway, looking at the original Lerna code:
https://github.com/lerna/lerna/blob/7bd983510110d00d9c3db94fb99f74773ab75d40/libs/commands/version/src/index.ts?#L811-L827

it is running npm install --package-lock-only --ignore-scripts that prevents to run the NPM hooks. So I don't know if it worths to do the same, just to avoid any issue in future when people migrate from Lerna to Lerna-lite

Anyway, looking at the original Lerna code: https://github.com/lerna/lerna/blob/7bd983510110d00d9c3db94fb99f74773ab75d40/libs/commands/version/src/index.ts?#L811-L827

it is running npm install --package-lock-only --ignore-scripts that prevents to run the NPM hooks. So I don't know if it worths to do the same, just to avoid any issue in future when people migrate from Lerna to Lerna-lite

hmm there is actually a CLI option runScriptsOnLockfileUpdate to pass for the command to ignore script, I guess we could add the same option in here too

Side note and as mentioned above you could also add the ignore script yourself via the npmClientArgs in the Lerna version command, so I guess something like this should work (untested), you can refer to the docs --npm-client-args

{
  "command": {
    "version": {
      "npmClientArgs": ["--ignore-scripts"]
    }
}

that is until I have time to add the other skip script run option. or you could also contribute the missing option 😉

Side note and as mentioned above you could also add the ignore script yourself via the npmClientArgs in the Lerna version command, so I guess something like this should work (untested), you can refer to the docs --npm-client-args

{
  "command": {
    "version": {
      "npmClientArgs": ["--ignore-scripts"]
    }
}

that is until I have time to add the other skip script run option. or you could also contribute the missing option 😉

Hi @ghiscoding, as I said, I already solved my problem but I will keep in mind this as future reference!
Thanks

latest release v3.6.0 will no longer run scripts when npm install runs, the behavior is now the same as Lerna and if you want to run the scripts then the new option runScriptsOnLockfileUpdate will let you do that (which is also the same option as Lerna)