custom publish command

[nosovk]

unfortunately for TS projects, especially Angular libs we often have to opt out from standard npm publish to custom script npm run publish.
See topic: https://stackoverflow.com/questions/38935176/how-to-npm-publish-specific-folder-but-as-package-root
often proposed workaround is using alternate publish script, like npm run publish that will do all the hacks.
Could you please add env variable npmpublish that will allow to override npm publish command with another non standard command.

[JamesMessinger]

That seems like a do-able feature. Do you have time to submit a PR?

[thetrompf]

@nosovk I think there is an easier way, and kind of out of scope. It can be achieved with too much orchestration in all of the 3 ways this package supports.

Github workflows: (a single line added).

---
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: actions/setup-node@v1
    - run: ./path/to/custom/build-script.sh
    - uses: JS-DevTools/npm-publish@v1
      with:
        token: YOUR_NPM_AUTH_TOKEN_HERE
        package: ./path/to/custom/package.json

Javascript package (a single line added).

const npmPublish = require("@jsdevtools/npm-publish");

// Do custom build stuff
const { execSync } = require('child_process');
execSync('./path/to/custom/build-script.sh');

// Run npm-publish with options
await npmPublish({
  package: "./path/to/custom/package.json",
  token: "YOUR_NPM_AUTH_TOKEN_HERE"
});

CLI (a single line added).

$ ./path/to/custom/build-script.sh && \
  npm-publish --token=YOUR_NPM_AUTH_TOKEN_HERE ./path/to/custom/package.json

I'm using this "technique" myself in this project.
https://github.com/orbit-online/task-runner/blob/7c9acb94b0ace2d9b1f6a7338c00144b3908a8c3/.github/workflows/npm-pubilsh-task-runner.yml

[mcous]

I think the requested functionality is either already available, via the package argument (which is really more akin to a working-directory argument) or the proposed package-spec argument, as detailed in #59.

Going to close this issue as already possible and/or duplicate. I think if you have more complex needs than those option are able to / will be able to service, you should be writing your own deploy logic rather than relying on this action