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 ...

[Adam Weinberger]

> On 18 May, 2017, at 9:34, David Naylor <naylor.b.david at gmail.com> wrote:
> 
> 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 a module, you simply download the tarball. For an app (see below), you'd be best off producing a bundle.

> 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.)

It will generally have its own node dependencies in a private tree of its own. And for that scenario, the required node modules should be bundled with the app itself. That's the whole idea behind the "new" paradigm: each app has separate copies of every module it needs, at exactly the version it wants.

> 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.

Yes, and in fact that's the main feature of the design. Let's say your app depends on foo-1.0, bar-1.0, and baz-1.0. And let's say that bar and baz both want foo-2.0. You will wind up with the foo module installed three times, at two different versions.

Dependencies of an app are private to that app. Dependencies of a dependency are private to that dependency, and so on.

> - 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.

True, but there isn't one now either. If you have foo-1.0 installed globally (i.e. from a port), and then you run "npm install" (local) from some app or module, npm will preferentially install a new copy of foo locally, no matter the version.

The only way to actually fix that is to have the problem patched upstream.

For the ports under question, though, no modification is being done. These ports simply installed the node modules verbatim with the ports mechanism instead of the npm mechanism.

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

They're quite relevant questions, because they're new territory for us all. I'm glad you're asking them.

# Adam


-- 
Adam Weinberger
adamw at adamw.org
https://www.adamw.org