Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add multiple new rules for "import" statements #806

Closed
feross opened this Issue Mar 2, 2017 · 5 comments

Comments

4 participants
@feross
Copy link
Member

feross commented Mar 2, 2017

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:

Thoughts welcome.

@feross feross added the enhancement label Mar 2, 2017

@feross feross added this to the standard v10 milestone Mar 2, 2017

@feross

This comment has been minimized.

Copy link
Member Author

feross commented Mar 2, 2017

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'
  1. 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

This comment has been minimized.

Copy link
Member Author

feross commented Mar 2, 2017

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

This comment has been minimized.

Copy link

tunnckoCore commented Mar 2, 2017

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

This comment has been minimized.

Copy link
Member

dcousens commented Mar 2, 2017

ACK

feross added a commit to standard/eslint-config-standard that referenced this issue Mar 2, 2017

feross added a commit to standard/eslint-config-standard that referenced this issue Mar 2, 2017

feross added a commit to standard/eslint-config-standard that referenced this issue Mar 2, 2017

feross added a commit to standard/eslint-config-standard that referenced this issue Mar 2, 2017

@LinusU

This comment has been minimized.

Copy link
Member

LinusU commented Mar 2, 2017

ACK

@feross feross closed this Mar 15, 2017

@lock lock bot locked as resolved and limited conversation to collaborators May 10, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.