Add multiple new rules for "import" statements

[feross]

In order to fix #599, we will depend on eslint-plugin-import in standard v10. This opens the possibility of enabling additional rules related to import and require().

The full list of rules is here: https://github.com/benmosher/eslint-plugin-import#rules

Many rules depend on how the files are loaded in the particular project, and I think we ought to avoid those rules since that will lead to some folks with complicated webpack loader rules unable to use standard without us exposing configuration options. And we don't want to go there.

So, of all the rules in there, these ones looked good to me:

• import/no-duplicates - better version of core no-duplicates rule which works with flow-type
• import/export - Reports funny business with exports, like repeated exports of names or defaults
• import/first - This rule reports any imports that come after non-import statements
• import/no-absolute-path - Forbid absolute imports like require('/home/xyz/file.js')
• import/no-webpack-loader-syntax - Forbid Webpack loader syntax in imports

Thoughts welcome.

[feross]

In the whole test suite, there were only two failures:

1. import/first failed because these import statements came after a require().

require('./styles.styl')

import React from 'react'
import {render} from 'react-dom'
import AmpRouter from 'ampersand-router'
import HomePage from './home-page'
import OtherPage from './other-page'

2. import/no-duplicates failed because these two import statements resolve to the same module

import Collection from '..'
import Index from '../index'

Can some folks who use the import syntax chime in with their thoughts? I still use require() for the time being so it would be good to hear other people's thoughts. @cesarandreu, who else can we tag here?

[feross]

I went ahead and merged all these rules for the standard v10 beta. I'm hoping to get some real-world usage from folks who have super large codebases using all the latest stuff, ES7+, babel, etc. If anything breaks, we can back out these rules in a future v10 beta release.

(Keeping this issue open for visibility.)

[tunnckoCore]

Addition sounds good to me.

As about 1) - I don't see any sense to use require there. Maybe it is using Webpack v1 which was not working with import/export syntax, so this exact stylus require is intentional because of the webpack.
edit: In anyway it won't be a problem to be change to import and I believe it would be working with Webpack v1 + Babel; and with just Webpack v2. So... no sense to be require

As about 2) make absolutely sense to error in that case. And preventing that is the right move.

[dcousens]

ACK

[LinusU]

ACK