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

Rebuild application when .eslintrc is changed #11

Open
dschmidt opened this issue Apr 21, 2015 · 3 comments
Open

Rebuild application when .eslintrc is changed #11

dschmidt opened this issue Apr 21, 2015 · 3 comments

Comments

@dschmidt
Copy link

Hey,

when adopting ember-cli-eslint you'll likely end up with a lot of warnings/errors and in turn you will
a) change your code a lot
b) change .eslintrc quite a bit to match your coding style/your globals/etc.

a) already rebuilds the application just fine, if you only change the .eslintrc (b)) you cannot immediately see if tests now pass. ... that would be nice though 👍

Best regards,
Dominik

@jonathanKingston
Copy link
Member

I have not got round to looking at this yet, I'm sorry about that.
Certainly I like the idea and certainly not against it, just have not had time to take a look. It isn't something complex however the outcome of some of the other outstanding issues might impact this one.

For example: if #13 and #14 are still causing issues the broccoli-lint-eslint might have to be changed as to how it calls the code (essentially reimplementing parts of ESLint so it can cope with nested .eslintrc files) which would be worth exposing as an API to solve this if it is needed.

So yeah, I thought I would chime in so you know I am not ignoring you.

Thank for the submission.

@Turbo87
Copy link
Member

Turbo87 commented Jul 12, 2016

@rwjblue @stefanpenner any pointers on how this could be implemented?

@stefanpenner
Copy link
Contributor

we currently don't watch the root of the project, largely because tmp and node_modules are present. I think with broccoli 1.0 allowing us to move the tmp dir to system temp we may be able to do this performantly. Alternatively, we could poll or just watch the root and deal with performance issues if they arise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants