Update all dependencies to their latest minor/patch version

.all-contributorsrc

@@ -88,7 +88,8 @@
       "avatar_url": "https://avatars3.githubusercontent.com/u/6643991?v=4",
       "profile": "https://michaeldeboey.be",
       "contributions": [
-        "maintenance"
+        "maintenance",
+        "tool"
       ]
     }
   ],

.changeset/README.md

@@ -1,36 +1,53 @@
 # Changesets
 
-Hello and welcome! This folder has been automatically generated by `@atlaskit/build-releases`, a build tool that works with `bolt` to help you release components from a mono-repository. You can find the full documentation for it [here](https://www.npmjs.com/package/@atlaskit/build-releases)
+Hello and welcome! This folder has been automatically generated by
+`@atlaskit/build-releases`, a build tool that works with `bolt` to help you
+release components from a mono-repository. You can find the full documentation
+for it [here](https://www.npmjs.com/package/@atlaskit/build-releases)
 
-To help you get started though, here are some things you should know about this folder:
+To help you get started though, here are some things you should know about this
+folder:
 
 ## Changesets are automatically generated
 
-Changesets are generated by the `build-releases changeset` command, though it may have been given a new name within your repository. As long as you are following a changeset release flow, you shouldn't have any problems.
+Changesets are generated by the `build-releases changeset` command, though it
+may have been given a new name within your repository. As long as you are
+following a changeset release flow, you shouldn't have any problems.
 
 ## Each changeset is its own folder
 
-We use hashes by default for these folder names to avoid collisions when generating them, but there's no harm that will come from renaming them.
+We use hashes by default for these folder names to avoid collisions when
+generating them, but there's no harm that will come from renaming them.
 
 ## Changesets are automatically removed
 
-When `build-releases version` or equivalent command is run, all the changeset folders are removed. This is so we only ever use a changeset once. This makes this a very bad place to store any other information.
+When `build-releases version` or equivalent command is run, all the changeset
+folders are removed. This is so we only ever use a changeset once. This makes
+this a very bad place to store any other information.
 
 ## Changesets come in two parts
 
 You should treat these parts quite differently:
 
-- `changes.md` is a file you should feel free to edit as much as you want. It will be prepended to your changelog when you next run your version command.
-- `changes.json` is a file that includes information about releases, what should be versioned by the version command. We strongly recommend against editing this directly, as you may make a new changeset that puts your bolt repository into an invalid state.
+- `changes.md` is a file you should feel free to edit as much as you want. It
+  will be prepended to your changelog when you next run your version command.
+- `changes.json` is a file that includes information about releases, what should
+  be versioned by the version command. We strongly recommend against editing
+  this directly, as you may make a new changeset that puts your bolt repository
+  into an invalid state.
 
 ## I want to edit the information in a `changes.json` - how do I do it safely?
 
-The best option is to make a new changeset using the changeset command, copy over the `changes.md`, then delete the old changeset.
+The best option is to make a new changeset using the changeset command, copy
+over the `changes.md`, then delete the old changeset.
 
 ## Can I rename the folder for my changeset?
 
-Absolutely! We need unique hashes to make changesets play nicely with git, but changing your folder from our hash to your own name isn't going to cause any problems.
+Absolutely! We need unique hashes to make changesets play nicely with git, but
+changing your folder from our hash to your own name isn't going to cause any
+problems.
 
 ## Can I manually delete changesets?
 
-You can, but you should be aware this will remove the intent to release communicated by the changeset, and should be done with caution.
+You can, but you should be aware this will remove the intent to release
+communicated by the changeset, and should be done with caution.

.changeset/config.js

@@ -35,7 +35,7 @@ const getReleaseLine = async (changeset, versionType) => {
     .join('\n');
 
   return `- [${versionType}] [${changeset.commit}](${getLink(
-    changeset.commit,
+    changeset.commit
   )}):\n${indentedSummary}`;
 };
 
@@ -54,12 +54,12 @@ const getDependencyReleaseLine = async (changesets, dependenciesUpdated) => {
   const changesetLinks = changesets.map(
     changeset =>
       `- Updated dependencies [${changeset.commit}](${getLink(
-        changeset.commit,
-      )}):`,
+        changeset.commit
+      )}):`
   );
 
   const updatedDepenenciesList = dependenciesUpdated.map(
-    dependency => `  - ${dependency.name}@${dependency.version}`,
+    dependency => `  - ${dependency.name}@${dependency.version}`
   );
 
   return [...changesetLinks, ...updatedDepenenciesList].join('\n');

.huskyrc.js

@@ -0,0 +1,5 @@
+module.exports = {
+  hooks: {
+    'pre-commit': 'pretty-quick --staged',
+  },
+};

.prettierrc.js

@@ -1,4 +1,6 @@
 module.exports = {
+  endOfLine: 'lf',
+  proseWrap: 'always',
   singleQuote: true,
-  trailingComma: 'all',
+  trailingComma: 'es5',
 };

.travis.yml

@@ -8,4 +8,4 @@ script:
   - yarn lint
 cache: yarn
 node_js:
-  - "node"
+  - 'node'

CODE_OF_CONDUCT.md

@@ -5,9 +5,9 @@
 In the interest of fostering an open and welcoming environment, we as
 contributors and maintainers pledge to making participation in our project and
 our community a harassment-free experience for everyone, regardless of age, body
-size, disability, ethnicity, sex characteristics, gender identity and expression,
-level of experience, education, socio-economic status, nationality, personal
-appearance, race, religion, or sexual identity and orientation.
+size, disability, ethnicity, sex characteristics, gender identity and
+expression, level of experience, education, socio-economic status, nationality,
+personal appearance, race, religion, or sexual identity and orientation.
 
 ## Our Standards
 
@@ -37,11 +37,11 @@ Project maintainers are responsible for clarifying the standards of acceptable
 behavior and are expected to take appropriate and fair corrective action in
 response to any instances of unacceptable behavior.
 
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, or to ban temporarily or permanently any
+contributor for other behaviors that they deem inappropriate, threatening,
+offensive, or harmful.
 
 ## Scope
 
@@ -58,17 +58,19 @@ Instances of abusive, harassing, or otherwise unacceptable behavior may be
 reported by contacting the project team at [email protected]. All
 complaints will be reviewed and investigated and will result in a response that
 is deemed necessary and appropriate to the circumstances. The project team is
-obligated to maintain confidentiality with regard to the reporter of an incident.
-Further details of specific enforcement policies may be posted separately.
+obligated to maintain confidentiality with regard to the reporter of an
+incident. Further details of specific enforcement policies may be posted
+separately.
 
 Project maintainers who do not follow or enforce the Code of Conduct in good
 faith may face temporary or permanent repercussions as determined by other
 members of the project's leadership.
 
 ## Attribution
 
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
-available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 1.4, available at
+https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
 
 [homepage]: https://www.contributor-covenant.org
 

CONTRIBUTING.md

@@ -2,23 +2,32 @@
 
 Thanks for considering contributing!
 
-This project has been developed to serve use-cases that I have encountered with uploading files to codesandbox, and definitely doesn't cover all use-cases. I'd be happy though if you find something else you need for you to contribute a pull request. I'll make sure you get a review quickly.
+This project has been developed to serve use-cases that I have encountered with
+uploading files to codesandbox, and definitely doesn't cover all use-cases. I'd
+be happy though if you find something else you need for you to contribute a pull
+request. I'll make sure you get a review quickly.
 
-If you're not confident raising a pull request, open an issue, and I can talk to you about the feature/bug fix you're looking for, and hopefully we can work out how to do it.
+If you're not confident raising a pull request, open an issue, and I can talk to
+you about the feature/bug fix you're looking for, and hopefully we can work out
+how to do it.
 
 ## For issues
 
-If you are reporting a bug, an attempt to understand where in our code the bug comes from, or an easy way to reproduce it is greatly appreciated!
+If you are reporting a bug, an attempt to understand where in our code the bug
+comes from, or an easy way to reproduce it is greatly appreciated!
 
-If you are requesting a feature, please make sure your use-case for the feature is clearly stated, so it's easy to evaluate.
+If you are requesting a feature, please make sure your use-case for the feature
+is clearly stated, so it's easy to evaluate.
 
 ## Deving on this project
 
-There are a couple of things that are probably good to know(TM) to dev on this project.
+There are a couple of things that are probably good to know(TM) to dev on this
+project.
 
 ### How do I get up and running?
 
-We are using [bolt](https://github.com/boltpkg/bolt) to manage this monorepo. If you haven't worked on a bolt project, the quick get-up-and-running steps are:
+We are using [bolt](https://github.com/boltpkg/bolt) to manage this monorepo. If
+you haven't worked on a bolt project, the quick get-up-and-running steps are:
 
 ```sh
 yarn global add bolt
@@ -30,17 +39,20 @@ The `bolt` command will install npm packages and link them.
 
 ### Observing changes
 
-If you are trying to observe changes across linked packages, you will need to make sure they are built.
+If you are trying to observe changes across linked packages, you will need to
+make sure they are built.
 
-`yarn build` builds all packages.
-`yarn dev:csb` runs the build script for `codesandboxer` and watches it for changes.
-`yarn dev:rcsb` runs the build script for `react-codesandboxer` and watches it for changes.
+`yarn build` builds all packages. `yarn dev:csb` runs the build script for
+`codesandboxer` and watches it for changes. `yarn dev:rcsb` runs the build
+script for `react-codesandboxer` and watches it for changes.
 
 The other packages do not need to be built.
 
 ### Validating changes
 
-Currently validation that things work is mostly being done through tests. The most important tests being the ones in `codesandboxer` and `codesandboxer-fs` which use the `/fixtures` directory to validate how they parse and load files.
+Currently validation that things work is mostly being done through tests. The
+most important tests being the ones in `codesandboxer` and `codesandboxer-fs`
+which use the `/fixtures` directory to validate how they parse and load files.
 
 ## Adding Templates
 
@@ -50,27 +62,44 @@ Codesandboxer currently supports:
 - create-react-app-typescript
 - vue-cli
 
-It should be easy to add new templates. Here are the places you would need to modify:
+It should be easy to add new templates. Here are the places you would need to
+modify:
 
-1. Add a template file to `packages/codesandboxer/templates/`.
-    A template should include a main file that imports from `example.js` (or the relevant filetype), as well as any other necessary files to run the sandbox.
-    1a. Once you have your template file, export it from `packages/codesandboxer/templates/index.js` added to the object with the name of the sandbox it is for.
-2. If you want a different template to be used for `codesandboxer-fs` add a template to `packages/codesandboxer-fs/templates` in the same way. (we tend to make templates for codesandboxer-fs call out the use of the sandboxer more explicitly, as it may be less clear how to debug it)
+1. Add a template file to `packages/codesandboxer/templates/`. A template should
+   include a main file that imports from `example.js` (or the relevant
+   filetype), as well as any other necessary files to run the sandbox. 1a. Once
+   you have your template file, export it from
+   `packages/codesandboxer/templates/index.js` added to the object with the name
+   of the sandbox it is for.
+2. If you want a different template to be used for `codesandboxer-fs` add a
+   template to `packages/codesandboxer-fs/templates` in the same way. (we tend
+   to make templates for codesandboxer-fs call out the use of the sandboxer more
+   explicitly, as it may be less clear how to debug it)
 
 ## For Pull Requests
 
 ### Code Standards
 
-We're using flow to help keep our code neat. If you could add types to your code, that would be 😎. Code that adds tests for its use-cases is also great.
+We're using flow to help keep our code neat. If you could add types to your
+code, that would be 😎. Code that adds tests for its use-cases is also great.
 
 ### Documentation
 
-If you add anything to the API, please update the documentation as well. (we also accept docs PRs if you see a way to improve our documentation)
+If you add anything to the API, please update the documentation as well. (we
+also accept docs PRs if you see a way to improve our documentation)
 
 ### Monitoring changes
 
-We are using [build-releases](https://www.npmjs.com/package/@atlaskit/build-releases) to add intents to change, so we can make sure our packages are released at the right semantic version. The simple answer is run `yarn changeset` and answer the questions. If you're not certain about semantic versioning, I would recommend checking out [this documentation](https://docs.npmjs.com/about-semantic-versioning).
+We are using
+[build-releases](https://www.npmjs.com/package/@atlaskit/build-releases) to add
+intents to change, so we can make sure our packages are released at the right
+semantic version. The simple answer is run `yarn changeset` and answer the
+questions. If you're not certain about semantic versioning, I would recommend
+checking out
+[this documentation](https://docs.npmjs.com/about-semantic-versioning).
 
 ## Please Be Nice
 
-I'm currently working on a code of conduct, but until that's ready, I wanted to make sure that everyone felt welcome here. If you are looking to contribute, please make sure you are respectful to anyone participating on this project.
+I'm currently working on a code of conduct, but until that's ready, I wanted to
+make sure that everyone felt welcome here. If you are looking to contribute,
+please make sure you are respectful to anyone participating on this project.