FLUID-6524: Migrate commonly used helper libraries to fluidproject organisation.

Description

Over the course of various grants, a few key helper libraries have been created that make it possible to do and/or test key things with Infusion. Now that the related grants are drawing to a close, it would be helpful to put these commonly-used libraries somewhere where a more active community can help maintain them.

Here is a list of packages that could potentially be migrated:

gpii-webdriver :check_mark:
gpii-express :check_mark:
gpii-glob :check_mark:
gpii-grunt-lint-all :check_mark:
gpii-grunt-mdjson-lint :check_mark: (collapsed into fluid-grunt-lint-all)
gpii-binder :check_mark:
gpii-diff :check_mark:
gpii-handlebars :check_mark:
gpii-json-schema :check_mark:
gpii-launcher :check_mark:
gpii-location-bar-relay :check_mark:
gpii-testem :check_mark:
gpii-pouchdb :check_mark:
gpii-mail-test (Required for gpii-express-user). :check_mark:
gpii-couchdb-test-harness :check_mark:

gpii-express-user :cross_mark: Still having trouble getting CI working.

Of those, I have heard from people using gpii-binder frequently, and I know the linting infrastructure is heavily used. gpii-glob is required by gpii-grunt-lint-all, so that one probably also has to come.

I suspect gpii-handlebars might be used, and I have heard from individuals in the community using gpii-webdriver and gpii-launcher.

:check_mark: = done
:info = pull request in progress
:cross_mark: = blocked

Comments

• Tony Atkins [RtF] commented 2020-07-03T04:17:50.865-0400

  I looked at the downloads and dependencies for each package and talked with people on IRC. I can tell that PhET uses gpii-launcher, and the Storytelling Tool uses gpii-handlebars. It's tougher to see the usage of test dependencies on npmjs.org, but from the downloads and people's comments on IRC, it sounds like all of the packages are worth migrating.

  I have thought about what needs to happen and here is my current idea about the rough process to follow:

  1. Remove the legacy repositories from Jenkins CI.
  2. Transfer the repositories to the fluidproject organisation.
  3. Submit a pull request to change each package name and component namespace.
  4. As part of each pull request, set up CI using GitHub Actions.
  5. Once the pull is merged, cut a release.
  6. Flag the released versions under the old name as deprecated with a note about the new package name.

  As many of these packages depend on each other, the updates need to flow through the various chains of interdependency. The simplest chain to convert is the linting infrastructure, in order, I'd need to convert:

  1. gpii-grunt-mdjson-lint
  2. gpii-grunt-lint-all

  This might be a good time to merge those into a single combined package as I believe @@Antranig Basman and I have previously discussed. One reason to do these first is that the CI setup is likely to be fairly simple and a good warmup for the rest of the "stack".

  The main "stack" has a few key dependencies that are used heavily. Most importantly, gpii-express needs to be migrated first among those. This has only node tests, and should not be particular challenging to set up CI for.

  The next tier are the common test dependencies, gpii-testem and gpii-webdriver, which are used in most packages that have browser tests. These are the first that require browsers, so the CI setup will presumably take longer. Hopefully the notes that @@Giovanni Tirloni left regarding migrating Infusion to Github Actions will save us time here.

  After that, we have enough to migrate gpii-binder, which is a key dependency of many remaining packages. Once gpii-binder is migrated, we can migrate gpii-handlebars and gpii-location-bar-relay.

  The last major project in the main stack is gpii-json-schema, which can only be migrated after gpii-binder, gpii-express, gpii-handlebars and gpii-webdriver are migrated. We should probably rename GSS to FSS or something while we're there.

  The gpii-launcher package is completely self contained and can be migrated separately as a one off. However, we should revisit the still open PR for the intiial effort and discuss what if anything we can fold in as part of the migration, such as using schemas to describe the inputs. If we want to update it to use schemas, it's be better to work on it near the end of the migration process so that I can put in one migration pull and then turn around and work on schematising things using the migrated gpii-json-schema.

• Gregor Moss commented 2020-07-03T13:24:02.974-0400

  I hope it all goes smoothly!

  Here's what's currently used by the Storytelling Tool, for reference:

  • Directly
    • gpii-binder
    • gpii-grunt-lint-all
    • gpii-handlebars
    • gpii-location-bar-relay
    • gpii-pouchdb (used to mock CouchDB in browser tests)
  • Via other deps
    • gpii-express
    • gpii-glob
    • gpii-grunt-mdjson-lint

• Tony Atkins [RtF] commented 2020-07-03T14:07:27.551-0400

  To be honest, I did not have real plans to support gpii-pouchdb moving forwards, as it requires supporting a fork of several very old versions of the underlying libraries. The forks are required for non-browser (i.e. node) usage, but maybe we can remove the non-browser parts as part of the migration, and then it would at least be a good starting point for people who use it more often (and much easier to maintain in general).

• Justin Obara commented 2020-07-08T17:15:15.037-0400

  @@Tony Atkins [RtF] what was the alternative you adopted for test in GPII? Did you just run a full instance of couchdb for it?

• Tony Atkins [RtF] commented 2020-07-09T03:54:11.019-0400

  Hi, Justin. The replacement used within the GPII is being migrated to fluid-couchdb-test-harness. The Fluid IoC test fixtures provided by that package can use a docker container, a Vagrant VM, or a standalone instance of CouchDB for local testing. I will likely set it up to use a docker container (which GitHub Actions supports) in CI.

  However, I have been trying to think of less disruptive ways to move forward. I will look at the current state of affairs when attempting to migrate fluid-pouchdb. It may be that we have a third option, i.e. abandoning our fork of the pouchdb stack in favour of a newer version that already works with node@12.

• Justin Obara commented 2020-07-09T07:21:15.651-0400

  @@Tony Atkins [RtF] thanks for the info/update.