Enhance documentation/ explain how it works about action HOT 13 CLOSED

Going to close this issue for now (thank you for the awesome conversation though @felipecrs), as it seems like a more general feature request over in volta itself.

from action.

RE: the volta internals, I think we'd need volta-cli/volta#282 to be resolved to avoid mutating package.json

from action.

Is it by running volta pin node@version?

Yep!

If so, does it leave the package.json modified?

Yes, it does. This is somewhat intentional, as I'm not sure where the package.json would be reversed. During the full run of the workflow (I suppose until the next run of the volta-cli/action action again) the node/yarn/npm versions specified in the actions config should "override" whatever happens to be in package.json.

from action.

I think this is a feature request for volta instead:

Support running temporary node versions

from action.

Support running temporary node versions

Hmm, I think this already exists.

Volta run --node=8 npm test

from action.

But it's not suitable for this action for example. It would be something like:

volta use node@8

from action.

I guess I don't understand what you are asking for. Currently we support two main modes of operation:

• pinning the project via node-version / yarn-version -- This would be used for the remainder of the action (or until the next invocation of the action changing node-version / yarn-version)
• using volta run -- This would run a specific command with the associated node / yarn versions; not modifying anything about future command line invocations.

What sort of timing / lifetime are you looking for?

from action.

I'm just looking for something that could be used by this action without changing package.json.

from action.

Why does the mutation of package.json matter in your case? Is there something that the current volta pin style override system breaks for your setup?

from action.

I use semantic-release in most of my projects, and during its execution, it updates the package.json with the new version to release, and commit this change back to GitHub.

In my case, I'm safe, since I don't call semantic-release in the same job which I set custom versions of node with volta.

Nonetheless, I can think of 2 cases where this would break:

1. For those who don't call semantic-release in a separate job (as advised in their own documentation, it only needs to be called after the npm test, not in other jobs AND the user uses this action to set the node version to run. The semantic-release would commit the newly pinned version of node back to GitHub.

2. For those who can use this action without pinning their versions in package.json, and still uses semantic-release. The semantic-release would commit the pinned version of node back to GitHub.

Side note: I'm now thinking about doing this deliberately, so I can keep my node and npm versions up-to-date automatically. :)

References volta-cli/volta#905.

from action.

Thanks for the explanation! I'm not sure there is a reasonable solution we can do here though. I can't think of a good heuristic that would allow us to reset that wouldn't also be annoying for non-release cases.

from action.

I thought in something like:

1. volta set node@8 -> writes the current directory and the desired version of node to $VOLTA_TEMP/set.json
2. node shim check for $VOLTA_TEMP/set.json before checking for package.json
3. volta unset node -> removes node from $VOLTA_TEMP/set.json

If you'd like, I can move this discussion to the main volta repo.

But for this repo, I think the current behavior should be documented, so the users would be at least aware of the package.json becoming (git) dirty in their pipelines.

from action.

But for this repo, I think the current behavior should be documented, so the users would be at least aware of the package.json becoming (git) dirty in their pipelines.

Yes, sounds good to me.

from action.