Add vlt

[lishaduck]

I know @​darcyclarke seems to generally be against Corepack, but I'd still like to be able to try out vlt... :)

[ljharb]

You can try it out with npx vlt, whether corepack supports it or not.

[aduh95]

You can also use --from-npm flag of Corepack, although it's still quite experimental

[lishaduck]

You can try it out with npx vlt, whether corepack supports it or not.

Yeah, right now I'm using deno install -g to aquire it, but I generally prefer to manage all of my Node package managers via Corepack. It's just easier.

You can also use --from-npm flag of Corepack, although it's still quite experimental

Good to know, thanks!

[darcyclarke]

First off, I find it odd that the reference @darcyclarke text isn't hyperlinked to my profile in the original post - does anyone know why that may be?

Secondly, you're right @lishaduck that our team does not want to be associated/distributed with corepack. There are numerous reasons why and I will not repeat them here (as you seem to be aware of my current position).

As @ljharb noted, you can use npm i -g vlt or npx vlt to use vlt client & those are our preferred & supported methods of installing the client today.

We will be offering alternative methods to directly install & self-manage the vlt client in the near future. As well, we plan to remove our implicit dependency on node, further distancing ourselves from the projects currently supported by corepack (ie. npm, pnpm & yarn are node programs & all have implicit dependencies on a compatible node binary). This strategy aligns vlt more closely to how bun or deno have historically bootstrapped their clients.

I think this issue can be closed.

[ljharb]

does anyone know why that may be?

There's a zero-width space after the @.

[lishaduck]

First off, I find it odd that the reference @darcyclarke text isn't hyperlinked to my profile in the original post - does anyone know why that may be?

I used a zero-width space, so that I wouldn't ping you. You're not a corepack maintainer, so I didn't think you'd be that interested, but you've collaborated, so I would have otherwise pinged you. (I suppose, given your position on corepack, that I should've known better)

Secondly, you're right @lishaduck that our team does not want to be associated/distributed with corepack. There are numerous reasons why and I will not repeat them here (as you seem to be aware of my current position).

As @ljharb noted, you can use npm i -g vlt or npx vlt to use vlt client & those are our preferred & supported methods of installing the client today.

Fair enough. I'd like to use corepack (at my own risk), but --from-npm is probably sufficient (vltpkg/vltpkg#249 is still breaking me, so I haven't tried it [--from-npm] yet). I see it like using Homebrew, community maintained, unofficial, but centralized.

We will be offering alternative methods to directly install & self-manage the vlt client in the near future. As well, we plan to remove our implicit dependency on node, further distancing ourselves from the projects currently supported by corepack (ie. npm, pnpm & yarn are node programs & all have implicit dependencies on a compatible node binary). This strategy aligns vlt more closely to how bun or deno have historically bootstrapped their clients.

I'd like to note that I wholeheartedly support moving away from [depending on] Node, even though I don't see how that makes it unable to corepacked.

I think this issue can be closed.

I'll close it then.

[darcyclarke]

I don't want to go too far down a rabbit hole here (as I stated before, critical feedback on this project & its implementation details is readily available to those that look for it) but I will respond to your specific sentiment/question:

I wholehearty support moving away from requiring node, even though I don't see how that makes it unable to corepacked.

1. I didn't mention it before but I do appreciate you trying out/using vlt (thank you 🙏🏻).
2. I never said that something could or couldn't be "corepacked".
   1. As far as I can tell, any project can be "corepacked" if Corepack's maintainers want to support it.
      1. Redistribution of third party software should be done with respect to licenses & the author's will.
      2. There is nothing preventing redistributors from subverting 2.i.a, knowingly or otherwise.
3. There is nothing inherently preventing vlt from being "corepacked".
   1. Corepack does not outline what makes a project out-of-scope.
      1. There is nothing preventing the subversion of mine - or other project maintainer's - preferences (ref. 2.i).
   2. Corepack does not outline what makes a project in-scope.
      1. The inclusion of a project seems entirely sentiment-driven¹.
4. I mentioned alignment as it is one criteria that I would, personally, think to consider in lieu of 3.i & 3.ii. corepack has the same implicit dependency on a compatible node binary that the current, supported tools have (because it is also a node program). This means there's a kind of "alignment" in that these tools (corepack, npm, yarn & pnpm) have a common runtime dependency & similar distribution mechanics. Alternatively, I reference bun & deno because those explicitly do not have dependencies on node & maintainers have noted they do not want to incur a node-specific performance penalty by being bootstrapped/managed by this tool (ex. [WIP] Add support for bun #307 (comment) / https://x.com/jarredsumner/status/1825322433131544833).
5. I commented "I think this issue can be closed." which was not authoritative (I have no standing) nor a request; it was/is my opinion. If you want to keep the issue open then that is up to you or the project collaborators. I just happen to think there isn't much more to discuss here.

• ¹ Being "sentiment-driven" is not inherently bad. Most open source projects are maintained by few individuals who often make preferential decisions on behalf of their own interests (which often align with a wider audience & thus, gain traction/adoption). Sometimes consumers of open source projects can influence the maintainer's decisions but the power of those end-users is only as powerful as the aligned incentives.
• ² As an aside, I personally do not believe it is in the Node project's best interest to support third-party projects which are either agnostic to &/or actively competitive with it as a server-side JavaScript runtime (but I digress).

[lishaduck]

I don't want to go too far down a rabbit hole here

Agreed. I don't intend on replying to any replies (though I probably will anyway 😁).

---

In response to 1: The GUI's great, even though it doesn't work as a PM for me, I've kept it installed.
In response to 2: You didn't say it couldn't be, but you did say you didn't desire it to be distributed via corepack. I respect your wishes under 2.i.a.¹
In response to 3: The ethical decision not to package it without your consent?
In response to 4: pnpm has @pnpm/exe, although it isn't used by corepack because the integrity hash is architecture-specific. Not that that invalidates the points about the (very real) Node perf penalty, but I still think a native vlt could be corepacked (as you stated in 3).
In response to 5: As I've stated, if you don't want to be packaged here, so be it. I recognize that you aren't a maintainer, but vlt is your (company's) project, and I'll respect that.
In response to ²: This isn't referenced above? I personally disagree that Node should be against agnosticism, but I agree that Corepack doesn't need to support Bun, Deno, etc (especially if they don't want to be packaged).

Footnotes

1. It's been a while since the remove Corepack debate surfaced to me. I thought you were against it to the extent that it's out of scope, redundant, and unnecessary, but not that you'd prefer not to be packaged here (which I see as a boon both for publicity and adoption). ↩

[lishaduck]

Oh, and I wanted to say I went back and reread what you'd written, @darcyclarke, and while I still disagree that corepack is redundant or that it should be removed from Node.js core, I find your actual points accurate, agreeable, and well thought out, and hope we, at least, can agree to disagree on this and move on with our lives. To civility 🥂
Happy holidays, and best of luck winning over JSLand!