I should have stepped in earlier. I am a bit concerned that this is bringing so many conventions which were not a part of this codebase before. We mostly do not need this work. If you want to add eslint, can you add it as the default, and we iterate from there?

Additionally, the real benefit here will be a github action travis config.

I am a bit concerned that this is bringing so many conventions which were not a part of this codebase before.

Sorry, I must've misinterpreted what you said. If you were interested in expanding the site w/ localization and things, I was thinking big. That requires quite a bit of engineering work to get done and I was trying to save you the effort of all this config.

@ljharb, you can disregard the second review — all of your concerns have been addressed.

This is pretty much as bare-bones as it gets. I don't think simplifying any further would be advantageos.

Please refer to the second take on this PR that is currently-open instead.

It reverts some of the early decisions we made:

• putting .prettierrc options in the .eslintrc
• attempting to style-check JSON using ESLint
• et al.

We actually do want to have a .prettierrc populated w/ this config for JSON style-checking.

Another thing that I did not address in this PR or the new one was creating a GitHub Action. I will have to followup w/ @codehag on that since I don't understand the reasoning behind it since Travis is already in use. Thanks so much for the tips though. I'm very pleased w/ the simplicity of the solution that resulted and welcome further scrutiny.

(linking to #214)

I will have to followup w/ @codehag on that since I don't understand the reasoning behind it since Travis is already in use.

Travis is better since it is what we use -- I was saying actions because I have that on another project and forgot that we were using travis here.