-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support alternative version pinning mechanism #282
Comments
/cc @mitsuhiko who also has been playing with Notion on some of our other projects and might have additional feedback |
Hi @dcramer, thanks for bringing this issue up! In our design discussions, we have always wanted to avoid adding a notion configuration file to a project, as we didn't want to add yet another required file that everyone who uses the tool would have to check in to source control. It seems like, for this use case, you would prefer a separate Notion configuration file, so that you can use that as a single source of truth that is distinct from Another possible option, if I'm interpreting your concern correctly, would be to have a Docker image that has Notion installed, and then let that Notion install handle fetching |
@charlespierce the docker image wont help us (we need base images and then to layer things on top). The main concern is that we want to be able to define a version via a filesystem object that is not in package.json. The reason is that we can In general I think this is going to be an ongoing industry-wide concern, but I've seen it's often not been approached in a way that works well with existing systems. The alternative is that whenever we change our Node.js or Yarn versions we have to update multiple locations. This issue is on the goal of trying to accomplish a singular canonical version reference, without compromising build caches (and thus build time/resources). If Notion decides "package.json is the standard and we dont want to have multiple locations" I think that's totally fair. Again, to me this is a general industry-wide problem that very few package management solutions have resolved. We got someone lucky that nvm was doable in a manner that worked for us, but Notion is easier for developers to work with out of the box. |
@dcramer you're not alone in that desire; I know of at least one other team for which that would make a big difference (my old team, which is also making good use of Docker in a not-dissimilar way)! |
Related: volta-cli/rfcs#33. |
FYI With the change to support
So that changing your Node / npm / Yarn version wouldn't require making a change to The main caveat with this is that with how |
I'm personally interested in this feature so that I can use Volta in my personal local environment without polluting the package.json of my open source projects. So the |
@frangio Understandable! While the approach I outlined is a solution to this issue, I don't think it's the solution since there are a number of problems with the usability. Can you expand on your use case a little? Are you looking to have a completely separate file that you can add to The former is potentially doable, though we'd need to make sure we're on top of performance and not trying to look in too many different places for files. The latter is difficult and I'm not sure really fits into the Volta data model. Out of curiosity, what is the hesitation regarding adding |
Yes exactly. The performance concern is very interesting though. Maybe there could be a limitation that this separate file has to be next to a The hesitation is because of a sort of "separation of concerns". I view Volta as a concern of my local setup, and as much as I love it and would recommend it to everyone, other developers may choose nvm (or anything else) and it wouldn't make sense to have duplicate configuration for all of these tools. I would've thought they'd all use the |
Related proposal from Twitter: Support the
If we can work out the specifics of how to handle the |
Hi - nvm maintainer here. The way nvm looks for an
I beg you not to support |
Hi @ljharb, thanks for the clarification on the specifics of The difference as I understand it (and please correct me if I'm wrong) is that nvm has an explicit command ( |
That's correct, yes - |
There is also the |
Pinning to |
@pho3nixf1re the semantics aren’t the same, for one because there are no agreed-upon semantics, but also because nvmrc supports anything nvm considers a “version-ish”, which includes user aliases, “iojs”, LTS aliases, etc. |
Sorry, let me clarify. I mean "the same" as in |
A separate config file support would be most appreciated. The use cases are also mentioned in #924. I understand the performance concern, so maybe it can be an opt-in feature. Side note: |
Volta is well on its way to be exactly what I'm looking for. The one feature that I'm missing is the I really like the features offered by If volta could support these same features, it'd be just jim-dandy. |
For possible interest, collection of |
Additional data point: in our project we do have The situation with volta is a bit different though because it allows pinning more than |
Wondering in how far it's still relevant to manage the package manager through Volta given that corepack exists now. Additionally, Yarn commits it's binaries to the repo now as well, pinning them effectively. Is there any benefit of keeping this extra functionality that is reducing the compatibility with nvmrc? |
Love Volta, on Windows it's probably the only sane Node version manager allowing me to work with multiple projects/components smoothly. That said, I don't want (and sometimes just can't) push that settings to all projects, so this is a real blocker, as both untracking +1 for |
Sorry to pile on, as a newcomer to Volta I just want to add my 2¢. IMHO I think it's become expected behaviour to have tool-specific configuration files in the root of a repository (monorepo or otherwise). These feel like fairly well-established patterns at this point (see: eslint, prettier, nvm, etc.) The majority of these tools all follow similar conventions:
So, given this pervasive pattern already exists, I guess I expected that it would be in place here as well. If I were a newcomer, I would not expect for Volta to read from an I feel that package.json-only-config doesn't work exceptionally well for a tool like this, as it must be committed to the repository and that can violate team standards. Without an alternate config method I'm forced to reach for something else 😕 By the way, thank you for this amazing tool I feel like it's the answer I've been looking for for quite some time! 👏👏👏👏👏 |
Related to this, here was my /2c as shared on a different issue:
|
|
For anyone else who ends up here looking for a possible workaround while this is implemented/resolved, I already had an alias set up to make it easy to navigate into my repo using ZSH and I just changed it to: alias mono=cd ~/PATH_TO_YOUR_REPO && volta install node@14.18.1 yarn@1.19.0 Now, whenever I hit mono to navigate into the repo, my preferred versions are selected by default. |
Further to @christiannaths comment I like the idea of a root I'm a big fan of Volta and have found pinning really useful where I can convince the whole team to adopt it. But since starting to contribute to a large well established OSS project I've realised the lack of pinning inheritance from the root of a monorepo is an issue. To have pinning work consistently across this project I will have to add |
A I would be able to add the file to my |
Would a PR be appreciated for adding support of |
NOTE: this issue predates this project's rename to Volta.
We love the idea of Notion (and nvm) as it makes it easier to persist a shared version of Node.js throughout many environments (local, Travis, production [Docker]). However, there's a limitation in Notion that we didn't have with nvm, and that comes from locking node/yarn within package.json itself.
This limitation realistically only comes up when you're doing layer caching, which if you're not familiar with I'm probably not a good person to learn from, but here we go:
We try to install Node and capture it outside of package.json because it means we dont have to rebuild the Node.js layer every time packages change.
Dockerfile
looks something like:Now this worked actually extremely well. We had a single file we could pull/parse to get the node version everywhere.
When moving to Notion our only real alternative is passing a Docker build arg:
This is fine and all, but tools like Google's Cloud Build (
cloudbuild.yaml
) doesn't let you do dynamic arguments like this. That means we're stuck with either rebuilding the Node.js layer every time package.json changes, or hardcoding NODE_VERSION elsewhere.I'm not proposing a solution here, but wanted to make sure everyones aware of this problem as its a shortcoming with a lot of package management tooling.
The text was updated successfully, but these errors were encountered: