Upgrade actions dependencies

[jisantuc]

Description of the change
This PR upgrades @actions/* where possible. The reason to do so is that GitHub changed the rules around add-path to address a security vulnerability.

---

Checklist:

• Added the change to the changelog's "Unreleased" section with a link to this PR and your username
• Linked any existing issues or proposals that this pull request should close
• Updated or added relevant documentation in the README and/or documentation directory
• Added a test for the contribution (if applicable) I believe that the existing addPath test should verify that this is fine

[colinwahl]

I went ahead and made this change and release v0.2.2 (I messed up v0.2.1 at first...).

I'm going through the steps to get it into the package-set, at which time we can update setup-purescript.

We should still get this change into main, I will come back to this tomorrow and we can work on it.

[jisantuc]

It feels a little bad that CI is mad about Data.Functor and Data.Array stuff from a js upgrade -- guessing that's 0.14.x related?

[thomashoneyman]

CI is broken because the 0.14 package set doesn’t currently build — we’re applying some changes to the functors and related libraries. That work will be done in the next day or two and CI will work again then. But if this builds successfully against 0.13.8 then we can still merge it; the CI issue is temporary and only because we’re in a transition right now along with many other core packages.

[jisantuc]

It does build against 0.13.8: 4a09406

I'll set a reminder to kick the build on Sunday unless y'all want to merge before then

[thomashoneyman]

All fixed! Thanks, @jisantuc.

[thomashoneyman]

Shouldn't we also deprecate the addPath function as is done in the patch we're upgrading to? We could also remove it altogether to get ahead of this change, though we're going to have to figure out what to do in setup-purescript instead.

There are plenty of references to addPath throughout the project code and documentation, including:

• The core docs
• The tool cache docs
• The core bindings and foreign file
• The tests

Fortunately we don't even have bindings for set-env so there's nothing to do there.

[jisantuc]

Shouldn't we also deprecate the addPath function as is done in the patch we're upgrading to?

Can we deprecate things in PS? I'm used to Scala's/Python's way of deprecating things with decorators. How do users find out about deprecations in PS?

[thomashoneyman]

You can use the Warn type class to emit a compiler warning with custom text, which is how we typically handle deprecations. See, for example, in the compiler repo:

https://github.com/purescript/purescript/blob/868eba2be75fb21fc958ed48ace2b6c0897e6640/tests/purs/warning/CustomWarning2.purs#L1-L13

In this case we'd do something like

addPath 
  :: Warn (Text "addPath is deprecated due to a security vulnerability and will be removed in the next release.") 
  => String
  -> Effect Unit

Then, when someone uses the function in their code they'll see a compiler warning containing that text.

[jisantuc]

Oh that's pretty cool 😎 add0212

[thomashoneyman]

This is the right idea — we do want to filter these out so as to not fail CI.

[thomashoneyman]

You can see an example of the syntax for filtering out warnings of this type here:
https://github.com/purescript/purescript-profunctor/blob/master/package.json

[jisantuc]

✅ 🎉 thanks for the pointer. Out of curiosity, will that exclude all user-defined warnings, even if a dependency adds a warning about something?

[thomashoneyman]

It will only censor user-defined warnings in this library. The —censor-lib flag censors warnings from library dependencies.