[discussion] Javascript package management (Yarn?)

Hi Hackers,

We've had some discussion on another thread
<https://www.postgresql.org/message-id/flat/CA%2BVc24pXOamfLgRx0LqGFFAdGRqUcKshpzEe0_%3D%3D-MExkWWx7g%40mail(dot)gmail(dot)com#CA+Vc24pXOamfLgRx0LqGFFAdGRqUcKshpzEe0_==-MExkWWx7g(at)mail(dot)gmail(dot)com>
in
the past couple weeks about pulling in npm to manage our javascript
dependencies.

I wanted to pull this discussion back up to the top level and hopefully get
some more input.

We recently moved the external front-end dependencies into a /vendor
directory to give some much needed clarity between what is pgadmin code and
what is vendor code, but we've continued to see some specific pains around
the javascript package management.

We discovered that the SlickGrid dependency was out of date and also had a
line commented out which prevented an event from firing. That kind of
modification to a vendor library can make it very difficult to understand
why the code is not behaving as expected.

When we went add a dependency on jasmine, Dave pointed out that we are
checking in lots of files that are not necessarily used but typically come
packaged with jasmine. My thinking was that it would be easier to upgrade
the dependency in the future if it was a simple drop-in and there was no
need to customize and pick apart what was in the directory. That said, it
does add extra bloat to our codebase when dependencies are checked in
wholesale.

Still, it brought back to mind that these issues would be resolved if we
were including the libraries using a package management tool.

libraries.txt appears to be a lo-fi manual package management system. It
has a record of the licenses that correspond to each library. If there is
concern about using a package manager and picking up libraries with
incompatible open source licenses, we could consider using a tool like
LicenseFinder to run as part of our build and ensure that libraries we are
depending on have licenses that make sense for the project.

Dave expressed concerns that this would be adding an extra burden to an
already complex development setup process.

Looking around at package managers, I wonder if Yarn might better address
some of the concerns about dependency availability and avoiding adding
extra steps to a build process. It's provided by Facebook under the BSD
license. It looks like they had some of the same concerns about wanting to
check in their dependencies but not wanting all the package bloat that
would come with checking in a node_modules directory. Thoughts?

Cheers,
Tira