Marked todo points as done.

FYI, I've added www/npm-node16.

I will prepare another diff that includes npm-node16 and all the modification, thanks a lot @sunpoet for your review!

Dear Luca,

I do not really understand your comment. Do you use application written in node on your servers?
I have many application out and most of them do not work with node 17 yet. Many dependencies have a block for node 17 in, so you cannot install them if you use node 17.

So this review tries to unbreak node for most users. One application that is in the ports is www/gitlab-ce. It does not work anymore with node 17, but with the LTS version 16.
But I cannot just use yarn-node16 because we have other dependencies which depend on node and node16 and node cannot be installed as they install same files, so we have here a collision.

The only way to really fix this (and most of the application we have in ports) define a default version and every port is then using this default version.
If you would like to use bleeding-edge version, you can overwrite the standard version.
But a normal user that is operating a FreeBSD cluster to run node application will never use the bleeding-edge version, but always an fully supported and maintained LTS version.

And this is what I would like to archive with this review.
So we do not break node for the user, we will unbreak it, because currently it is broken and you cannot use it for many dependencies.

Hi Matthias,
I guess it's my turn to not understand your comment.
I'm not arguing that it's a good idea to have lts as default version, but I want to split this change in two patches, because it's a breaking change, and more changes are needed.

I don't see the problem. If your application doesn't work with node17, you can specify USES=nodejs:lts , as you proposed, already. But if you want to use yarn AND node17, you have to rebuild your portstree.
The reason to have yarn, yarn-node16 and yarn-node14 (same goes for npm) was to avoid to build the portstree, but to choose the version of nodejs you want to use by installing the proper package. With your patch, there is no way to use node17 but to rebuild packages.

Hence, specify USES=nodejs:16 or USES=nodejs:lts (for now, see the last comment)

This is what I don't understand: how can you have other dependencies which depend on node and node16? You can only one node version installed at a time.
So, you cannot to use yarn-node16 and yarn, because of conflicting dependencies. It has been built in this way on purpose to chose, with the package, which node version you want to use.

I'm not disagreeing with this, but if I want to try node17 with npm or yarn (because without package manager, there is little or no use for nodejs), I have to rebuild the packages, changing the default version.
npm-* and yarn-* were introduced to avoid it.

IMO, the long-term solution, is to have a node-devel port for the version in development, node for the latest lts, and nodeXX for the older lts, as many other ports.
What I'm saying, here is to focus this patch on introducing USES=node and move the discussion of default version in a following review.

Maybe, to ease the process, yarn-lts and npm-lts can be introduced...

Dear Luca,

ok, I think I understood what you want.
At first (as already noted) I will split this commit into two, currently they are here:
https://gitlab.fechner.net/mfechner/Gitlab/-/commits/nodejs_default_version

Yes we should make yarn available with each version combination without forcing the user to compile anything. I suggest we make this possible by just adding www/yarn-node17:

# Created by: Luca Pizzamiglio <pizzamig@FreeBSD.org>

PKGNAMESUFFIX=  -node17

CONFLICTS_INSTALL=      yarn

USES=           nodejs:17,run

MASTERDIR=      ${.CURDIR}/../yarn

.include "${MASTERDIR}/Makefile"

I will also prepare an entry in UPDATING to explain there the change in a way a normal user will understand it.
I suggest to also add npm-node17 to be consitent.

I will update the commits and the attached diff here.

I will do some tests and will provide a new diff later.

I commited it now to unbreak gitlab-ce which is now for nearly 2 weeks broken, we can fine tune it in a second round.