I'm new to the node package jungle. Looks like corepack provide more or less the
same feature as npx but restricted to package managers. I have no idea whats the
difference for my use case.

The issue I have with this approach are DISTFILES and the work todo for
something that isn't needed atm (using devel/yarn).

I started on electron+vscode using pre-made tgz for this reason. If I remember
correclty it was a pre-made cache so yarn can work offline.
As I can't host it in long term, I finally wrote a module for yarn and npm. The
yarn module convert the lock in a cache directory for yarn. The npm module
convert the lock in node_modules directoy without using npm (that's an other
story ...).

I did not find any example of corepack / npx call from port itself.
FreeBSD have a step to prepare distfiles so they can use corepack to prefetch
but I prefer OpenBSD way and I don't want to change the ports system.

We can have a yarn module just like cargo (without makefile) but then I need to
identify & extract the approriate version (1...4) to bundle it (and I need to
figure out how). I have no use case to test yarn>1 neither I tried. From what I
read moving from one to the other break something so I think that's easier to
follow what the port was built with and avoid fighting this ecosystem.

If the need arise (a port which require yarn>1 or maybe pnpm) then we can work
on a corepack-like module and perhaps put everything in node module. I like this
idea, and you ?

Actually there is a lot to say about this ecosystem and I had some hearth attack
on my way to make those two modules ... but the results is nice.

In conclusion if we remove yarn I will just add the distfile to the module and
also a variable for invocation, that's not corepack but that's easy.

From my point of view, keeping it until I replace it doesn't hurt.

On 27/03/2024 08:58, Volker Schlecht wrote:
> Did you check if corepack yarn is a viable option for you? electron may be an
> exception, but the projects I've come across so far don't need a globally
> installed yarn command anymore.
> 
> On 2024-03-26 23:36, Fabien ROMANO wrote:
>> Please no, I'm working on electron and I need it.
>>
>> VSCode works for me on amd64 (also stretchly, byar, signal-desktop).
>> I don't know a lot about Yarn port itself but we can improve it for sure.
>>
>> I think that's too early to bring my wip on ports@ but it's a start.
>> If some brave souls want to help, I can share, just contact me.
>>
>> On 26/03/2024 20:10, Volker Schlecht wrote:
>>> Picking up on that discussion from September:
>>>
>>> devel/yarn is
>>>
>>> - unsupported upstream
>>> - unmaintained
>>> - unused
>>> - outdated
>>>
>>> ok to remove?
>>>
>>> On 2023-09-19 21:43, Volker Schlecht wrote:
>>>> On Tue Sep 19, 2023 at 9:05 PM CEST, Aaron Bieber wrote:
>>>>> On 9/19/23 13:00, Volker Schlecht wrote:
>>>>> > Cc: abieber@
>>>>> >
>>>>> > I just came across our port of devel/yarn, which appears to be both very
>>>>> > old and by now, very underutilized.
>>>>> >
>>>>> > The last discussions about yarn that I saw on the list were about WIP
>>>>> > efforts to port VSCode, to which an ancient devel/yarn doesn't seem to
>>>>> > be the key either.
>>>>> >
>>>>> > Any reason to still keep it around?
>>>>>
>>>>> Probably not. The MainReason™ for the port was to give people a working
>>>>> yarn. Out of the box
>>>>> it doesn't know the path to `node`.
>>>>
>>>> With no regard to my: Is that still a problem since we fixed that with a
>>>> metaphoric hammer?
>>>>
>>>> https://github.com/openbsd/ports/blob/master/lang/node/patches/patch-src_env_cc
>>>

-- 
Fabien Romano