svn commit: r440978 - in head: devel devel/npm-amdefine devel/npm-clean-css devel/npm-clean-css/files devel/npm-commander devel/npm-commander/files devel/npm-graceful-readlink devel/npm-source-map ...

[David Naylor]

On Wednesday, 17 May 2017 20:53:35 Adam Weinberger wrote:
> For these reasons, node modules and Go modules simply are not good
> candidates for FreeBSD ports. npm manages node modules in the correct node
> way (and pkg doesn't), and so npm is the correct way to install node
> modules. I'm sure Go has a similar tool; I'll call it gopher because that
> sounds like a good name for a Go installer, and I'm sure that it installs
> Go modules the correct way, and so it is the correct way to install Go
> modules.
> 
> There are definitely exceptions to this: if a module must be modified in a
> specific way to work on FreeBSD, or if a module is a required dependency of
> another port, then having those modules in the tree definitely makes sense.

Thank you for explaining your reasons, and for the better understanding of the 
intricacies of node packages (and npm).  

I think we are still stuck with the problem of needing a way to download the 
required npm files during the fetch phase (and have those files verified).  

For nuget we reproduced that logic in USES=mono (which is simply download and 
extract).  There was the possibility to define a custom cache location from 
which nuget would do the extracting (and leave the downloading to the Ports 
framework), however I never got it to work.  I also think paket not work that 
way.  

Also, could you please clarify a point: Lets say I have a node package (say 
electron) that needs to be modified and compiled to run on FreeBSD.  It 
obviously has it's own node dependencies.  Will npm include those dependencies 
as private or would ports need to be created for them?  (My npm knowledge is 
next to non-existent.)

Also, some bike-shedding (dark blue please): In general, I am wary of the 
"new" way:

 - Consistency: if every program based on node.js bundled their own version of 
the library then updates are dependent on the software creator.  It is likely 
to have multiple versions (some with known issues/vulnerabilities) of a 
"package" to be installed.  

 - Alter-ability: there would no longer be a central place where one can make 
custom changes to a node package (for whatever reason) and have all users of 
that package automatically pick it up.  

These issues, however, are more "meta" in nature and are tangential to the 
practical issue of software propagation and deployment.  

Regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freebsd.org/pipermail/svn-ports-all/attachments/20170518/41cdfb9a/attachment.sig>