Re: [pgadmin-hackers][discussion] Javascript package management (Yarn?) - Mailing list pgadmin-hackers

Hi

On Thu, Mar 2, 2017 at 6:11 PM, Atira Odhner <aodhner@pivotal.io> wrote:
> Hi Hackers,
>
> We've had some discussion on another thread 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.

Actually that file is there because we (EDB) often have customer's
legal departments demand lists of all the Open Source code and
projects that we use in any of our products. By listing the bundled
packages there we save ourselves (and any other Postgres companies
that distribute pgAdmin or a derived product) the pain of having to
regularly collate an up to date list.

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

It certainly looks good in a quick look, but I still think there are
issues to consider:

- Whilst it cuts down on the bloat caused by unnecessary files in the
source tree, it does nothing to prevent the problem in the packages we
distribute to users (installers, app bundles, RPMs etc) which are the
primary concern in this are (I can live with bloat in the source tree,
but minimising bloat in the final packages is high priority).

- It's using the NPM repository, and as far as I can see doesn't offer
a way to add packages that aren't in NPM (short of publishing them to
there ourselves). This means no wcDocker, no aciTree and no
Filemanager (though - on reflection we may have actually forked that
one). We'd either have to have users manually add those, or continue
to keep them in-tree.

In short, I can see how yarn solves some of these problems for us, but
it doesn't solve all of them. The first will bloat packages, and the
second will require us to continue with some things in-tree in all
likelyhood (though at least two of the possible 3 of those are
modified anyway).

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company