After replacing static/fonts with a symlink I loaded 0.0.0.0:7936 to verify that the test program still works.

The code changes look fine to me. I'm not too familiar with submodules, but it seems like they add some extra overhead.

In particular (gathered from https://medium.com/@porteneuve/mastering-git-submodules-34c65e940407):

1. Every time you add a submodule, change its remote’s URL, or change the referenced commit for it, you demand a manual update by every collaborator.
2. Forgetting this explicit update can result in silent regressions of the submodule’s referenced commit.
3. Commands such as status and diff display precious little info about submodules by default.
4. Because lifecycles are separate, updating a submodule inside its container project requires two commits and two pushes.
5. Submodule heads are generally detached, so any local update requires various preparatory actions to avoid creating a lost commit.
6. Removing a submodule requires several commands and tweaks, some of which are manual and unassisted.

Should the readme be updated to help contributers understand how to work with the new submodule for fonts?

I have a few git aliases set to help with managing submodules:

  # Versions of commands that handle submodules properly.
  co = "!f() { git checkout \"$@\" && git submodule update --init --recursive; }; f"
  p = "!f() { git pull \"$@\" && git submodule update --init --recursive; }; f"
  m = "!f() { git merge \"$@\" && git submodule update --init --recursive; }; f"
  gsu = "!f() { git submodule sync --recursive && git submodule update --init --recursive; }; f"

I agree that it definitely adds additional overhead. Another option would be to turn the new font repo into a npm module.

Hmm, an npm module is an interesting idea. The copying of fonts to dist is part of npm install anyway, so we can rely on modules being installed...

I agree it's an interesting idea. Would there be any concerns with turning that code into an npm module?

Although I made the suggestion, I have a couple concerns about using npm modules:

• it can be harder to test changes the require changes to code across modules. In this case I don't think that would really be an issue because you can inspect the font files and see if the glyphs are there (or not)
• probably fewer people will be willing/able to publish the npm module. This could be worked around by pointing to the git repo directly and specifying a particular sha.

FWIW, npm link offers one way to test changes between the two repos, without having to npm publish. Probably not quite as convenient as submodules though, where you have everything right there in the same tree. Submodules are also closer to our current approach.

I do feel like it's good to optimize for people who don't care about (developing) the fonts, and there is a slight advantage there. On the other hand, it doesn't take much training to learn git submodules --update (if that's the right command).

Back to the PR, did you test npm start? (I don't know off hand whether this triggers build.)
Do the release scripts need to change at all?

@edemaine the release script runs make dist which run make build which copies over the font files to the build/fonts same as before so release.sh should just work.

I'll double check npm start tonight and see if the test page works.

After having thought of it a little more, I think using a submodule should serve just fine. I'm finding it hard to think how you'd use semver for a font repo. It just feels a little odd.

The code here looks fine, have you had a chance to test via npm start?

have you had a chance to test via npm start?

😭 just been really busy with other stuff lately. Running npm start shouldn't take that long though, going to try to get to it this evening.

@rrandallcainc I ran npm start and then loaded http://0.0.0.0:7936 and saw:

I'm going to take @rrandallcainc's suggestion of updating CONTRIBUTING.md to provide some tips on how to deal with submodules.

@rrandallcainc I've added a section to CONTRIBUTING.md title "Working with submodules".