Add fixtures, and test for Link component with package json

.gitignore

@@ -3,3 +3,4 @@ node_modules
 coverage
 dist
 *.log
+.idea

src/utils.js

@@ -37,7 +37,7 @@ export const isSingleFile = (path: string): boolean => {
 }
 
 export const getFiles = (cwd: string, componentName?: string): string[] => {
-  const extensions = '{js,ts,jsx,tsx,css,less,scss}'
+  const extensions = '{js,ts,jsx,tsx,css,less,scss,json}'
   const pattern = componentName ? `**/${componentName}{.,.*.}${extensions}` : `**/*.${extensions}`
   return glob.sync(pattern, { cwd, absolute: true, nodir: true })
 }

test/fixtures/react-static-boilerplate/.editorconfig

@@ -0,0 +1,20 @@
+# EditorConfig helps developers define and maintain consistent
+# coding styles between different editors and IDEs
+# http://editorconfig.org
+
+root = true
+
+[*]
+
+# Change these settings to your own preference
+indent_style = space
+indent_size = 2
+
+# We recommend you to keep these unchanged
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[*.md]
+trim_trailing_whitespace = false

test/fixtures/react-static-boilerplate/.gitattributes

@@ -0,0 +1,16 @@
+# Automatically normalize line endings for all text-based files
+# http://git-scm.com/docs/gitattributes#_end_of_line_conversion
+* text=auto
+
+# For the following file types, normalize line endings to LF on
+# checkin and prevent conversion to CRLF when they are checked out
+# (this is required in order to prevent newline related issues like,
+# for example, after the build script is run)
+.*      text eol=lf
+*.css   text eol=lf
+*.html  text eol=lf
+*.js    text eol=lf
+*.json  text eol=lf
+*.md    text eol=lf
+*.txt   text eol=lf
+

test/fixtures/react-static-boilerplate/.gitignore

@@ -0,0 +1,14 @@
+# Include your project-specific ignores in this file
+# Read about how to use .gitignore: https://help.github.com/articles/ignoring-files
+
+# Compiled output
+public/dist
+public/index.html
+public/sitemap.xml
+
+# Node.js and NPM
+node_modules
+npm-debug.log
+
+# Firebase
+firebase-debug.log

test/fixtures/react-static-boilerplate/.travis.yml

@@ -0,0 +1,14 @@
+language: node_js
+node_js:
+  - '6'
+env:
+  - CXX=g++-4.8
+addons:
+  apt:
+    sources:
+      - ubuntu-toolchain-r-test
+    packages:
+      - g++-4.8
+script:
+  - npm run lint
+  - npm run test

test/fixtures/react-static-boilerplate/CONTRIBUTING.md

@@ -0,0 +1,143 @@
+# Contributing to React Static Boilerplate
+
+♥ **React Static Boilerplate** and want to get involved? Thanks! There are plenty of ways you can
+help!
+
+Please take a moment to review this document in order to make the contribution process easy and
+effective for everyone involved.
+
+Following these guidelines helps to communicate that you respect the time of the developers managing
+and developing this open source project. In return, they should reciprocate that respect in
+addressing your issue or assessing patches and features.
+
+
+## Using the issue tracker
+
+The [issue tracker](https://github.com/kriasoft/react-static-boilerplate/issues) is the preferred
+channel for [bug reports](#bugs), [features requests](#features) and [submitting pull
+requests](#pull-requests), but please respect the following restrictions:
+
+* Please **do not** use the issue tracker for personal support requests (use [Stack
+  Overflow](https://stackoverflow.com/questions/tagged/react-starter-kit)).
+
+* Please **do not** derail or troll issues. Keep the discussion on topic and respect the opinions
+  of others.
+
+* Please **do not** open issues or pull requests regarding the code in
+  [`React`](https://github.com/facebook/react),
+  [`Redux`](https://github.com/reactjs/redux),
+  [`Babel`](https://github.com/babel/babel) or
+  [`Webpack`](https://github.com/webpack/webpack) (open them in their respective repositories).
+
+
+<a name="bugs"></a>
+## Bug reports
+
+A bug is a _demonstrable problem_ that is caused by the code in the repository. Good bug reports are
+extremely helpful - thank you!
+
+Guidelines for bug reports:
+
+1. **Use the GitHub issue search** &mdash; check if the issue has already been reported.
+
+2. **Check if the issue has been fixed** &mdash; try to reproduce it using the latest `master` or
+   development branch in the repository.
+
+3. **Isolate the problem** &mdash; ideally create a [reduced test
+   case](https://css-tricks.com/reduced-test-cases/) and a live example.
+
+A good bug report shouldn't leave others needing to chase you up for more information. Please try to
+be as detailed as possible in your report. What is your environment? What steps will reproduce the
+issue? What browser(s) and OS experience the problem? What would you expect to be the outcome? All
+these details will help people to fix any potential bugs.
+
+Example:
+
+> Short and descriptive example bug report title
+>
+> A summary of the issue and the browser/OS environment in which it occurs. If suitable, include the
+> steps required to reproduce the bug.
+>
+> 1. This is the first step
+> 2. This is the second step
+> 3. Further steps, etc.
+>
+> `<url>` - a link to the reduced test case
+>
+> Any other information you want to share that is relevant to the issue being reported. This might
+> include the lines of code that you have identified as causing the bug, and potential solutions
+> (and your opinions on their merits).
+
+
+<a name="features"></a>
+## Feature requests
+
+Feature requests are welcome. But take a moment to find out whether your idea fits with the scope
+and aims of the project. It's up to *you* to make a strong case to convince the project's developers
+of the merits of this feature. Please provide as much detail and context as possible.
+
+
+<a name="pull-requests"></a>
+## Pull requests
+
+Good pull requests - patches, improvements, new features - are a fantastic help. They should remain
+focused in scope and avoid containing unrelated commits.
+
+**Please ask first** before embarking on any significant pull request (e.g. implementing features,
+refactoring code, porting to a different language), otherwise you risk spending a lot of time
+working on something that the project's developers might not want to merge into the project.
+
+Please adhere to the coding conventions used throughout a project (indentation, accurate comments,
+etc.) and any other requirements (such as test coverage).
+
+Adhering to the following process is the best way to get your work included in the project:
+
+1. [Fork](https://help.github.com/articles/fork-a-repo/) the project, clone your fork, and configure
+   the remotes:
+
+   ```bash
+   # Clone your fork of the repo into the current directory
+   git clone https://github.com/<your-username>/react-static-boilerplate.git
+   # Navigate to the newly cloned directory
+   cd react-static-boilerplate
+   # Assign the original repo to a remote called "upstream"
+   git remote add upstream https://github.com/kriasoft/react-static-boilerplate.git
+   ```
+
+2. If you cloned a while ago, get the latest changes from upstream:
+
+   ```bash
+   git checkout master
+   git pull upstream master
+   ```
+
+3. Create a new topic branch (off the main project development branch) to contain your feature,
+   change, or fix:
+
+   ```bash
+   git checkout -b <topic-branch-name>
+   ```
+
+4. Commit your changes in logical chunks. Please adhere to these [git commit message
+   guidelines](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) or your code is
+   unlikely be merged into the main project. Use Git's [interactive
+   rebase](https://help.github.com/articles/about-git-rebase/) feature to tidy up your commits
+   before making them public.
+
+5. Locally merge (or rebase) the upstream development branch into your topic branch:
+
+   ```bash
+   git pull [--rebase] upstream master
+   ```
+
+6. Push your topic branch up to your fork:
+
+   ```bash
+   git push origin <topic-branch-name>
+   ```
+
+7. [Open a Pull Request](https://help.github.com/articles/using-pull-requests/) with a clear title
+   and description.
+
+**IMPORTANT**: By submitting a patch, you agree to allow the project owners to license your work
+under the terms of the [MIT License](LICENSE.txt).

test/fixtures/react-static-boilerplate/LICENSE.txt

@@ -0,0 +1,21 @@
+                            The MIT License
+
+Copyright (c) 2015-present Kriasoft, LLC. All rights reserved.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.