hunk.code_window: exports[`defaults - snapshot 1`] = `
   <Creatable
     allowCreateWhileLoading={false}
     createOptionLabelFirst={false}
     defaultInputValue=""
     defaultMenuIsOpen={false}
     defaultValue={null}
     formatCreateLabel={[Function]}
     getNewOptionData={[Function]}
  
hunk.labels: keep keep keep replace keep keep keep keep keep
hunk.after_edit:   createOptionPosition="last"
  
hunk.file_path: src/__tests__/__snapshots__/Creatable.test.js.snap
hunk.type: replace
file: # Contributing
  
  Thanks for your interest in React-Select. All forms of contribution are
  welcome, from issue reports to PRs and documentation / write-ups.
  
  * We use node.js v4+ for development and testing. Due to incompatibilities with
  JSDOM and older versions of node.js, you'll need to use node 4 and above to run the
  tests.  If you can't install node v4 or above as your "default" node installation, you
  could try using [nvm](https://github.com/creationix/nvm) to install multiple
  versions concurrently.
  * If you're upgrading your node.js 0.x environment, it's sometimes necessary
  to remove the node_modules directory under react-select, and run npm install
  again, in order to ensure all the correct dependencies for the new version
  of node.js (as a minimum, you'll need to remove the `jsdom` module, and
  reinstall that).
  
  Before you open a PR:
  
  * If you're planning to add or change a major feature in a PR, please ensure
  the change is aligned with the project roadmap by opening an issue first,
  especially if you're going to spend a lot of time on it.
  * In development, run `npm start` to build (+watch) the project source, and run
  the [development server](http://localhost:8000).
  * Please ensure all the examples work correctly after your change. If you're
  adding a major new use-case, add a new example demonstrating its use.
  * Please **do not** commit the build files. Make sure **only** your changes to
  `/src/`, `/less/` and `/examples/src` are included in your PR.
  * Be careful to follow the code style of the project. Run `npm run lint` after
  your changes and ensure you do not introduce any new errors or warnings.
  
  * Ensure that your effort is aligned with the project's roadmap by talking to
  the maintainers, especially if you are going to spend a lot of time on it.
  * Make sure there's an issue open for any work you take on and intend to submit
  as a pull request - it helps core members review your concept and direction
  early and is a good way to discuss what you're planning to do.
  * If you open an issue and are interested in working on a fix, please let us
  know. We'll help you get started, rather than adding it to the queue.
  * Make sure you do not add regressions by running `npm test`.
  * Where possible, include tests with your changes, either that demonstrates the
  bug, or tests the new functionality. If you're not sure how to test your
  changes, feel free to ping @bruderstein
  * Run `npm run cover` to check that the coverage hasn't dropped, and look at the
  report (under the generated `coverage` directory) to check that your changes are
  covered
  * Please [follow our established coding conventions](https://github.com/keystonejs/keystone/wiki/Coding-Standards)
  (with regards to formatting, etc)
  * You can also run `npm run lint` - our linter is a WIP
  but please ensure there are not more violations than before your changes.
  * All new features and changes need documentation. We have three translations,
  please read our [Documentation Guidelines](https://github.com/keystonejs/keystone/wiki/Documentation-Translation-Guidelines).
  
  * _Make sure you revert your build before submitting a PR_ to reduce the chance
  of conflicts. `npm run build` is run after PRs are merged and before any
  releases are made.
  