# How to make a dependency on npm-node12 or higher?



## JonnySac (May 21, 2021)

Hello,
I am making a port, and I was wondering what the proper solution is to the following dependency question.  The software I am porting has a build and run dependency on Node.js v12 or higher (and actually yarn-node >= 12 also).  Since there are separate ports for each LTS version, npm-node12 and npm-node14, how do I specficy a dependency for version 12 or greater?  As of now I just have a dependency for v14 which I guess I can live with but I figure it would be nice to not force people to have to upgrade from v12 to v14.  Any ideas?  Thank you!!


```
BUILD_DEPENDS=  npm-node14>0:www/npm-node14 \
                yarn-node14>0:www/yarn-node14

RUN_DEPENDS=    npm-node14>0:www/npm-node14
```


----------



## zirias@ (May 21, 2021)

Unfortunately, you can't.

Situations like this are often handled using the "default versions" mechanism (together with some USES helpers in Mk/Uses), but for node, no such mechanism exists (yet?)

What you _can_ do is to implement your own OPTIONS for it. But I don't think it's worth the hassle, other ports already depend on the node-14 ports, so the pragmatic solution would be to just go with that.


----------



## SirDice (May 21, 2021)

I'd depend on the master port for this, instead of a specific version. 

```
BUILD_DEPENDS= yarn>=1.10.0:www/yarn
```

The default of www/node is node16.


----------



## zirias@ (May 21, 2021)

SirDice said:


> I'd depend on the master port for this, instead of a specific version.


Careful with that…

For build dependencies, this is mostly fine. You might have to worry about consistency of the dependencies though…
For run and lib dependencies, don't do that. It will lead to a package having a dependency on the _specific_ package, which tools like `poudriere` will interpret as a changed dependency, causing a rebuild on every run
To _really_ solve the issue, node would have to be added to Mk/bsd.default-versions.mk. Maybe someone wants to do this


----------



## SirDice (May 21, 2021)

It's always useful to look at existing ports, devel/py-widgetsnbextension for example has a build dependency on www/npm.


----------



## zirias@ (May 21, 2021)

SirDice said:


> It's always useful to look at existing ports, devel/py-widgetsnbextension for example has a build dependency on www/npm.


Yes, I think for _build_ dependencies, it should be fine  Just saying, be careful


----------



## SirDice (May 21, 2021)

Oddly enough there's no port that has a _run_ dependency on any of the npm versions. 

Also note that www/node12 has disappeared and www/npm-node12 will be soon (strange since it depends on node12, why is it still around?), so I wouldn't include it for anything new.

Probably the best way to deal with this is to make it _optional_. Depend on www/node by default but allow a switch to www/node14.


----------



## zirias@ (May 21, 2021)

Btw, I might have been mistaken: maybe using such a "meta-port" as a _run_ dependency works as well, would have to test that. It definitely breaks with _lib_ dependencies, see for example PR 244497.

Anyways, it's not really solving the problem, as the meta-port also has a dependency on the current default version. The canonical mechanism to solve these things is "default versions". It's just: _someone_  would have to implement it for node.

For now, I'd just depend on the "default" version of node-related ports unless my port explicitly requires using an older version. I guess that's what other ports are doing…


----------



## SirDice (May 21, 2021)

The first thing I looked for was a `USES` for node, but that doesn't seem to exist (yet?). That would probably solve a lot of these issues (`DEFAULT_VERSIONS+= node=14` for example). 

Failing that, a "radio" type option selection seems like a good solution.


----------



## zirias@ (May 21, 2021)

SirDice said:


> The first thing I looked for was a `USES` for node, but that doesn't seem to exist (yet?). That would probably solve a lot of these issues (`DEFAULT_VERSIONS+= node=14` for example).


Yes, adding it to Mk/bsd.default-versions.mk would go with providing a Mk/Uses/node.mk  That would be the "correct" solution.

Usage _should_ look like, you said, in the user's make.conf: `DEFAULT_VERSIONS+= node=14`, and in the port's Makefile something like:

```
USES=     node:12+
USE_NODE=      node yarn
```

But nobody implemented support for that so far 



SirDice said:


> Failing that, a "radio" type option selection seems like a good solution.


Agreed again, although I'd probably skip that as other ports don't do this either, and maintaining it with node moving forward is more work than just adapting your manual dependency lines


----------



## covacat (May 21, 2021)

```
#ugly hack
THE_NODE!=pkg query '%v' npm-node11 npm-node-13 npm-node12|| exit 0
.if $(THE_NODE) == ""
BDEPS+=www/node14
.else
#BDEPS+=none
.endif
```


----------



## zirias@ (May 21, 2021)

covacat while you can probably get that to work, it would never be accepted in the ports tree: it introduces "automagic" dependencies based on the system the port is built on


----------



## JonnySac (May 21, 2021)

Thank you everyone for your responses!! So I will just use `npm-node14` for right now, then in the next version of the port maybe add an option to select a node version.

Yes, I was a bit surprised as I was reading the Porters Handbook, I kept expecting to see a chapter on Node. Due to the current, and increasing popularity of Node, it would definitely be a worthwhile endeavor to implement a proper `DEFAULT_VERSIONS` for it. I don't know enough about Mk/bsd.default-versions.mk to tackle something like that yet but maybe as I get more familiar with it.


----------



## zirias@ (May 21, 2021)

As I said, someone should probably do it eventually  (which, in an opensource environment, translates to "whoever feels capable and entitled", hehe)

*edit:* If you ever feel like tackling this, make sure to request a Phabricator account to submit the change there for review. Such changes should be properly reviewed and Bugzilla isn't the best tool for that


----------

