autoformat files, #216

checklists/code-review-checklist.md

@@ -72,10 +72,9 @@ If any of these items fail, pause code review.
   Results can be found in {{GITHUB_ISSUE_LINK}}.
 - [ ] For each common-code component (sun, scenery-phet, vegas, …) that opaquely registers observers or listeners, is
   there a call to that component’s `dispose` function, or is it obvious why it isn't necessary, or is there
-  documentation
-  about why `dispose` isn't called? An example of why no call to `dispose` is needed is if the component is used in
-  a `ScreenView` that would never be removed from the scene graph. Note that it's also acceptable (and encouraged!) to
-  describe what needs to be disposed in implementation-notes.md.
+  documentation about why `dispose` isn't called? An example of why no call to `dispose` is needed is if the component
+  is used in a `ScreenView` that would never be removed from the scene graph. Note that it's also acceptable (and
+  encouraged!) to describe what needs to be disposed in implementation-notes.md.
 - [ ] Are there leaks due to registering observers or listeners? The following guidelines should be followed unless
   documentation (in-line or in implementation-notes.md) describes why following them is not necessary.
   * AXON: `Property.link` or `lazyLink` is accompanied by `unlink`.
@@ -121,10 +120,8 @@ If any of these items fail, pause code review.
   with query parameters `stringTest=double` and `stringTest=long`)
 - [ ] Does the sim stay on the sim page (doesn't redirect to an external page) when running with the query parameter
   `stringTest=xss`? This test passes if sim does not redirect, OK if sim crashes or fails to fully start. Only test on
-  one
-  desktop platform. For PhET-iO sims, additionally test `?stringTest=xss` in Studio to make sure i18n strings didn't
-  leak
-  to phetioDocumentation, see https://github.com/phetsims/phet-io/issues/1377
+  one desktop platform. For PhET-iO sims, additionally test `?stringTest=xss` in Studio to make sure i18n strings didn't
+  leak to phetioDocumentation, see https://github.com/phetsims/phet-io/issues/1377
 - [ ] Avoid using concatenation to create strings that will be visible in the user interface. Use `StringUtils.fillIn`
   and a string pattern to ensure that strings are properly localized. This is relevant in cases where order should be
   translatable.
@@ -207,9 +204,9 @@ Nested substructure is not yet fully supported.
 
 - [ ] The repository name should correspond to the sim title. For example, if the sim title is "Wave Interference", then
   the repository name should be "wave-interference".
-- [ ] Are all required files and directories present?
-  For a sim repository named “my-repo”, the general structure should look like this (where assets/, images/, mipmaps/ or
-  sounds/ may be omitted if the sim doesn’t have those types of resource files).
+- [ ] Are all required files and directories present? For a sim repository named “my-repo”, the general structure should
+  look like this (where assets/, images/, mipmaps/ or sounds/ may be omitted if the sim doesn’t have those types of
+  resource files).
 
   ```
   my-repo/
@@ -242,12 +239,11 @@ Nested substructure is not yet fully supported.
 - [ ] Verify that the same image file is not present in both images/ and mipmaps/. If you need a mipmap, use it for all
   occurrences of the image.
 
-- [ ] Is the js/ directory properly structured?
-  All JavaScript source should be in the js/ directory. There should be a subdirectory for each screen (this also
-  applies for single-screen sims, where the subdirectory matches the repo name). For a multi-screen sim, code shared by
-  2 or more screens should be in a js/common/ subdirectory. Model and view code should be in model/ and view/
-  subdirectories for each screen and common/. For example, for a sim with screens “Introduction” and “Lab”, the general
-  directory structure should look like this:
+- [ ] Is the js/ directory properly structured? All JavaScript source should be in the js/ directory. There should be a
+  subdirectory for each screen (this also applies for single-screen sims, where the subdirectory matches the repo name).
+  For a multi-screen sim, code shared by 2 or more screens should be in a js/common/ subdirectory. Model and view code
+  should be in model/ and view/ subdirectories for each screen and common/. For example, for a sim with screens
+  “Introduction” and “Lab”, the general directory structure should look like this:
 
   ```
   my-repo/
@@ -300,10 +296,9 @@ Nested substructure is not yet fully supported.
 
 - [ ] Are coding conventions outlined
   in [PhET's Coding Conventions Document](https://github.com/phetsims/phet-info/blob/main/doc/coding-conventions.md)
-  followed and adhered to? This document
-  deals with PhET coding conventions. You do not need to exhaustively check every item in this section, nor do you
-  necessarily need to check these items one at a time. The goal is to determine whether the code generally meets PhET
-  standards.
+  followed and adhered to? This document deals with PhET coding conventions. You do not need to exhaustively check every
+  item in this section, nor do you necessarily need to check these items one at a time. The goal is to determine whether
+  the code generally meets PhET standards.
 
 ## **TypeScript Conventions**
 
@@ -333,8 +328,9 @@ Nested substructure is not yet fully supported.
 - [ ] Is composition favored over inheritance where appropriate?
   See https://en.wikipedia.org/wiki/Composition_over_inheritance.
 - [ ] Is there any unnecessary coupling? (e.g., by passing large objects to constructors, or exposing unnecessary
-  properties/functions). If you only need a few fields from a large object, pass them in as separate parameters.  The threshold for
-  the number of parameters is up to you - use your judgement. Alternatively in TypeScript, you can decouple by narrowing the API using `Pick`, but this is a bit of a hack. Here's an example:
+  properties/functions). If you only need a few fields from a large object, pass them in as separate parameters. The
+  threshold for the number of parameters is up to you - use your judgement. Alternatively in TypeScript, you can
+  decouple by narrowing the API using `Pick`, but this is a bit of a hack. Here's an example:
 
 ```ts
   public constructor( tickMarksVisibleProperty: Property<boolean>,
@@ -412,18 +408,17 @@ This section may be omitted if the sim has not been instrumented for PhET-iO, bu
   This could be an extensive bullet. At the very least, be sure to know what amount of instrumentation this sim
   supports. Describing this further goes beyond the scope of this document.
 - [ ] PhET-iO instantiates different objects and wires up listeners that are not present in the PhET-branded simulation.
-  It needs to be tested separately for memory leaks. To help isolate the nature of the memory leak, this test should
-  be run separately from the PhET brand memory leak test. Test with a colorized Data Stream, and Studio (easily
-  accessed from phetmarks). Compare to testing results done by the responsible developer and previous releases.
+  It needs to be tested separately for memory leaks. To help isolate the nature of the memory leak, this test should be
+  run separately from the PhET brand memory leak test. Test with a colorized Data Stream, and Studio (easily accessed
+  from phetmarks). Compare to testing results done by the responsible developer and previous releases.
 - [ ] Make sure unused `PhetioObject` instances are disposed, which unregisters their tandems.
 - [ ] Make sure JOIST `dt` values are used instead of `Date.now()` or other Date functions. Perhaps try
   `phet.joist.elapsedTime`. Though this has already been mentioned, it is necessary for reproducible playback via input
   events and deserves a comment in this PhET-iO section.
 - [ ] Are random numbers using `DOT/dotRandom` as an imported module (not a global), and all doing so after modules are
-  declared (non-statically)? For
-  example, the following methods (and perhaps others) should not be
-  used: `Math.random`, `_.shuffle`, `_.sample`, `_.random`.
-  This also deserves re-iteration due to its effect on record/playback for PhET-iO.
+  declared (non-statically)? For example, the following methods (and perhaps others) should not be
+  used: `Math.random`, `_.shuffle`, `_.sample`, `_.random`. This also deserves re-iteration due to its effect on
+  record/playback for PhET-iO.
 - [ ] Like JSON, keys for `undefined` values are omitted when serializing objects across frames. Consider this when
   determining whether `toStateObject` should use `null` or `undefined` values.
 - [ ] PhET prefers to use the term "position" to refer to the physical (x,y) position of objects. This applies to both

checklists/employee-leaving-checklist.md

@@ -10,10 +10,12 @@
 ### Turn in all university property to Physics department or PhET:
 
 - [ ] Door Keys. If needed, can be mailed to:
-  Facilities Management Access Services
-  University of Colorado Boulder
-  UCB 53
-  Boulder, CO 80309
+    ```
+    Facilities Management Access Services
+    University of Colorado Boulder
+    UCB 53
+    Boulder, CO 80309
+    ```
 - [ ] Buff OneCard and Eco Pass
 - [ ] A-Card or US Bank Cards
 - [ ] Library materials

checklists/postmortem-process.md

@@ -4,8 +4,8 @@
   sufficient time for the meeting, 1.5-2 hours.
 
 - [ ]  **2. Enlist a meeting moderator**
-- The moderator's job is to make sure the meeting runs efficiently, stays on point, and focuses on constructive (but
-  not overly negative) criticism. The moderator can be someone not on the sim team, or in many cases the Development
+- The moderator's job is to make sure the meeting runs efficiently, stays on point, and focuses on constructive (but not
+  overly negative) criticism. The moderator can be someone not on the sim team, or in many cases the Development
   Coordinator. The moderator also documents the important points of the meeting.
 
 - [ ]  **3. Create github postmortem issue and postmortem google doc**

checklists/rename-repo-checklist.md

@@ -35,5 +35,4 @@
 - [ ] Run `grunt modulify`
 - [ ] update usages of the Namespace file
 - [ ] Looks through all usages in the repo of the previous name to make sure issues links, comments and code are
-  updated.
-  This especially applies to imports for the namespace and strings.
+  updated. This especially applies to imports for the namespace and strings.

conduct/communication-guidelines.md

@@ -63,8 +63,7 @@ intent/voice is harder to gauge in places github comments
 5. If talking directly is ineffective OR if you do not feel comfortable initiating the conversation in the first place,
    speak to a supervisor.
 
-Notes from dev discussion 07/11/2019
-It’s not about efficiency. It’s about creating a supportive environment.
+Notes from dev discussion 07/11/2019 It’s not about efficiency. It’s about creating a supportive environment.
 
 Concern that it will take more time. How to balance.
 

deployment-info/chipper-1.0.md

@@ -23,8 +23,8 @@ try using chipper 2.0 steps but just building and deploying each brand separatel
 Before building or deploying a simulation, familiarize yourself with configuration options for PhET's build process.
 
 Your default build configuration is specified in `~/.phet/build-local.json`. Describing or identifying the entries
-in `build-local.json` is beyond the scope of this document; ask a PhET developer for help in setting up this file. At
-a minimum you will need `devUsername` and `buildServerAuthorizationCode`. A few handy keys:
+in `build-local.json` is beyond the scope of this document; ask a PhET developer for help in setting up this file. At a
+minimum you will need `devUsername` and `buildServerAuthorizationCode`. A few handy keys:
 
 * `buildServerNotifyEmail`: add your email to be notified on the success or failure of your builds to the build server.
 * `brand:phet` to automatically build the phet brand instead of the adapted-from-phet brand.
@@ -64,37 +64,32 @@ and the simulation will be built and deployed.
 * **RC_FIRST**:
   + **PHET_IO:**: Add `-phetio` to the end of the branch name.
   + Create a branch with MAJOR.MINOR matching the sim to be published, such as 1.2. For instance: `git checkout -b 1.2`
-  + Update the version id in package.json for main. Main should be set up for what
-    would be the _next_ release branch name. So if you just created release branch 1.3, then the version should be "
+  + Update the version id in package.json for main. Main should be set up for what would be the _next_ release branch
+    name. So if you just created release branch 1.3, then the version should be "
     1.4.0-dev.0" in main. (Note the "0" for the dev number, so that `grunt bump-version` works properly.)
 * **RC_SUBSEQUENT | PRODUCTION**:
   + Checkout the branch with MAJOR.MINOR (**PHET_IO** branches will end with `-phetio`). If a branch does not exist for
-    your
-    version, make, following the step above, like you are publishing the first rc.
+    your version, make, following the step above, like you are publishing the first rc.
   + `grunt checkout-shas` to checkout any supporting branches from other repos.
   + If checkout-shas didn't already do so: `npm prune` and `npm update` in the sim repo and in chipper.
     `rm -rf node_modules` and `npm install` in that directory instead.
   + **Maintenance Release**:  If you needed to branch any dependency repositories for the purposes of patching, name the
-    branches
-    after the sim and version you are performing the maintenance release on. For example,
+    branches after the sim and version you are performing the maintenance release on. For example,
     running `git checkout -b graphing-lines-1.1` in the vegas repository will branch vegas for use by the graphing-lines
     1.1 branch.
   + **Maintenance Release**:  After the commits have been made, update the top level `dependencies.json` to reflect the
     new shas and branches of the maintenance release. When you deploy, this step should be done automatically. This top
     level `dependencies.json`
     is only important for checking out shas.
   + **Maintenance Release**:  If there is a parallel brand that has the same minor number as your branch (i.e. 1.3 and
-    1.3-phetio), it
-    means that these branches should have the same shas (not always true in practice, but mostly accurate, so check your
-    shas). Make
-    sure that all of your commits are cherry-picked onto that branch too (if they apply), so that the branches stay in
-    sync.
+    1.3-phetio), it means that these branches should have the same shas (not always true in practice, but mostly
+    accurate, so check your shas). Make sure that all of your commits are cherry-picked onto that branch too (if they
+    apply), so that the branches stay in sync.
 * **PRODUCTION**: Update the QA credits before continuing.
 * **PHET PRODUCTION_FIRST**: Complete the simulation main checklist (beyond the scope of this document). Notably, this
   includes adding a screenshot so that thumbnails and the twitter card are properly generated in the initial deployment.
 * **ALL RC and PRODUCTION**: please see https://github.com/phetsims/chipper/issues/587 for a description of branch names
-  and
-  how to keep phet and phet-io branch names in sync
+  and how to keep phet and phet-io branch names in sync
 
 ## Step 2. Update the version number in package.json
 
@@ -128,10 +123,9 @@ Use version names of the following form:
 * **RC**: `grunt deploy-rc` RC versions are deployed to spot.colorado.edu
   at http://www.colorado.edu/physics/phet/dev/html/
 * **PRODUCTION**:
-  This will instruct the build server to build the English version of
-  the simulation as well as all currently deployed translated versions and deploy them on the web site. This will also
-  deploy
-  the locally built version to the dev server.
+  This will instruct the build server to build the English version of the simulation as well as all currently deployed
+  translated versions and deploy them on the web site. This will also deploy the locally built version to the dev
+  server.
   + Generally: `grunt deploy-production`
   + **NOTE**: If you're using a version of chipper that is from _**Nov 9, 2015**_ or earlier, add `--locales=*`.
   + For ph-scale and ph-scale-basics, ignore the above 'Note' and always use `grunt deploy-production`.
@@ -149,31 +143,29 @@ Use version names of the following form:
 * **PHET_IO**:
   + Test using the wrapper index, located at {{SIM}}/{{VERSION}}/wrappers/index.
   + You will need a password. Verify that your password works.
-* Run Step 4, but for the published version. NOTE: A username and password are required to test deployed wrappers
-  for phet-io versions. Ask a PhET developer for credentials.
+* Run Step 4, but for the published version. NOTE: A username and password are required to test deployed wrappers for
+  phet-io versions. Ask a PhET developer for credentials.
 
 ## Step 7. Post-publication steps
 
 * **PRODUCTION FOR PHET_BRAND**:
-  + **NEW_SIM**: Both the simulation and project will need to marked "visible" in the website admin interface.
-    Usually the person in charge of uploading all of the meta information will be responsible for doing this. After
-    that,
-    make sure the sim page appears correctly on the website. Talk to @jonathanolson or @jbphet if it has not appeared
-    after marking the sim and project visible.
+  + **NEW_SIM**: Both the simulation and project will need to marked "visible" in the website admin interface. Usually
+    the person in charge of uploading all of the meta information will be responsible for doing this. After that, make
+    sure the sim page appears correctly on the website. Talk to @jonathanolson or @jbphet if it has not appeared after
+    marking the sim and project visible.
     - When viewing the website you may encounter stale content due to the varnish cache. There are two ways to avoid
       this:
       - To check a small number of issues, add a unique parameter to the end of every query. You must change it every
-        time you
-        refresh the url.
+        time you refresh the url.
         Example: `https://phet.colorado.edu/sims/html/example-sim/latest/example-sim_en.html?test-parameter1`
-      - To avoid the cache permanently, you need to add a cookie with the name `NO-CACHE` and with an arbitrary or
-        empty value. Cookie usage cannot be covered in entirety here. To use cookies with `curl`
+      - To avoid the cache permanently, you need to add a cookie with the name `NO-CACHE` and with an arbitrary or empty
+        value. Cookie usage cannot be covered in entirety here. To use cookies with `curl`
         see [this answer](http://stackoverflow.com/a/7186160/2496827). To add custom cookies in
         Chrome [see this solution](http://superuser.com/a/636697/493443).
   + **INITIAL_PUBLICATION**: Generate and check in (on the main branch) the auto-generated readme file for a published
     sim. The README.md file can be created using ```grunt published-README```.
-  + **NOT_A_NEW_SIMULATION**: Verify that any previously existing translations are still available and that
-    their version numbers are correct.
+  + **NOT_A_NEW_SIMULATION**: Verify that any previously existing translations are still available and that their
+    version numbers are correct.
 * **PRODUCTION FOR PHET_IO_BRAND**:
   + If this is a version that will be used with students, then make sure to remove the password protection.
     See https://github.com/phetsims/phet-io/blob/main/doc/phet-io-security.md for details.