Date: Fri, 19 May 2017 23:51:12 +0200 From: Rodrigo Osorio <rodrigo@osorio.me> To: Adam Weinberger <adamw@adamw.org>, David Naylor <naylor.b.david@gmail.com> Cc: Rodrigo Osorio <rodrigo@freebsd.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: 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 ... Message-ID: <0551d587-a2f9-ab34-fbbc-ea5f979dacf0@osorio.me> In-Reply-To: <6CD1FD4D-5EF7-4562-84E3-FBA1825A0F01@adamw.org> References: <201705152205.v4FM5kIw055373@repo.freebsd.org> <1917876.5GWQEAK6S8@dragon.local> <33786079-3935-478C-9F5B-9B46B4483CDB@adamw.org> <1806880.NXCOkgnAQa@dragon.local> <6CD1FD4D-5EF7-4562-84E3-FBA1825A0F01@adamw.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello everyone, On 05/18/17 17:48, Adam Weinberger wrote: >> On 18 May, 2017, at 9:34, David Naylor <naylor.b.david@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. That's what the new ports does, www/npm-less-plugin-clean-css is a www/lessc plugin to compress css outputs. The other ports are just dependencies. And www/lessc is in the ports tree since 2015. >> 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. Npm not only install the downloaded application, it also download the dependencies recursively, and nobody knows how many dependencies a project needs or will need, at least before the end of the install. It's also impossible to predict for a package which version will be installed. >> 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. This is not true, npm itself performs deduplication during the install and after, removing duplicate packages, preserving only the latest versions regardless of the version requested by the packages (https://docs.npmjs.com/cli/dedupe). As we can see npm itself violates its owns private dependency rules. > - 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 <rude>In my opinion, npm is nothing but a poor designed tool, who tends to install over and over the same packages trying to upgrade them and replacing local packages by global ones regardless of the requested version letting you live in a dangerous word</rude> My submission is probably far from perfect but I think we can try to make npm packages usage safe for the users. best regards, -- rodrigo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0551d587-a2f9-ab34-fbbc-ea5f979dacf0>