🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

@jonathanKingston I recently bumped the package version after merging the recent changes that were pegged to the milestone and drafted a new release, but I don't appear to have NPM publishing perms at the moment. I didn't realize that -- so apologies for getting too far ahead with the bump -- but perhaps a quick publish could be made to keep everything in sync.

What are your thoughts on allowing the test generator to determine what counts as failing?

Currently, the test generator is passed a list of error/warning messages, but has no way of differentiating between errors and warnings. This forces warnings to be treated as fail-worthy. If instead the result object was passed to the test generator, the test generator would be responsible, and thus free to, decide whether warnings are fail-worthy or not.

Here's a diff of more or less what's needed to make this work: nickiaconis@4b15c56

Would you be interested in something like this?

The ESLint.create() API is not mentioned in the README.md, and it should be.

/cc @Turbo87

Howdy! Im trying to use the ember-cli-eslint module that uses broccoli-lint-eslint, its throwing that error when I try to build or test and if we add the persistent output flag to true here
https://github.com/ember-cli/broccoli-lint-eslint/blob/master/lib/index.js#L66

It seems to fix it for us. Do you have any idea what could be causing this or how we could fix it? Or any information as to what IS the persistent output flag

To get parity with: https://github.com/rwjblue/broccoli-jshint

Add in documentation for all features and including: #2

see #95 (review)

The dependency broccoli-persistent-filter was updated from 2.0.0 to 2.1.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

broccoli-persistent-filter is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

ESLint has lately introduced support for using an .eslintrc.js file among other formats which adds the ability to include comments into the files. Would it be possible to add support for those files to the plugin too?

Version 1.2.2 of broccoli-merge-trees just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As broccoli-merge-trees is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Sorry if this is a double submit. I searched the issues and dug into the code but couldn't find anything.

Should a file be subject to the full cascaded eslint ruleset based on it's file location? I have a subdir, mirage, that I want to loosen my rules on. eslint cli correctly picks up the custom .eslintrc.js file in the directory, overrides the base config (project root) and lints fine. ember-cli is not picking up the nested config.

This line sort of implies that the config is just based on root and maybe there's special processing for the config in the tests dir?

I could fix the linting errors or add in-file rule config, but wanted to ensure I wasn't missing something here first.

Some of the logic (e.g. here) depends on *nix-like paths, and therefore causes breakage on Windows.

I'm testing and putting together a pull-request now. If people are seeing breakages with the latest version of this or related packages on Windows, this is probably the reason.

This plugin should make a good example to others and should then use eslint-config-nightmare-mode in its tests.

Hi!

I am using the default mocha testGenerator for eslint like this
var eslint = ESLint.create(js, {testGenerator: 'mocha'});

The tests that are generated for files that successfully passes eslint are fine however when a test i generated that fails I get the follwing error running mocha

ReferenceError: chai is not defined

If I look closer at the test file that is generated chai is used but not imported

describe('ESLint | js/Image.js', function() {
  it('should pass ESLint', function() {
    // test failed
    var error = new chai.AssertionError('js/Image.js should pass ESLint\n\n60:1 - Trailing spaces not allowed. (no-trailing-spaces)');
    error.stack = undefined;
    throw error;
  });
});

should something like const chai = require('chai'); be added to each test file? Or is this something I can set globally in mocha?

Hey friends,
I want to have Ember Build break on ESLint Errors.

Is this possible currently with this library or would I need to go and do this manually somewhere?

I found this but it is relevant to JSHint: https://discuss.emberjs.com/t/force-build-failure-on-any-jshint-error/7060/5

If I implemented a feature to apply the ESLint fixes to the output directory, would that be accepted? Just want to get some confirmation that that would be desirable before starting work on it.

Adding fix: true to the options passed on to the ESLint Node API isn't quite enough to actually makes the changes; you also have to invoke outputFixes.

My plan right now would be to add another top-level config option, applyFixes, which would allow the user of the plugin to optionally choose to transform the files as well as lint them. We could also just check to see if fix was supplied in the options that are passed on to the ESLint Node API, but I'm hesitant to do that since the Node API does not actually apply the fixes when that option is supplied. It might be confusing if our behavior differs from theirs.

lib/index.js, line 94 now uses an arrow function. This breaks node versions which do not support arrow functions (seemingly for a non-critical reason).

Edit: It seems that eb58bd8 was to use ES6? Afaik, this still requires the --harmony flag with node, and this is causing syntax errors via ember-cli-eslint for me. \

Edit2: This is because this change was a minor version release, despite breaking backwards compatibility, and because ember-cli-eslint depends on ^1.1.1,

Getting the following error while trying to run ember build

package.json

"devDependencies": {
    "broccoli-asset-rev": "^2.4.5",
    "broccoli-merge-trees": "2.0.0",
    "broccoli-lint-eslint": "4.2.1", // --> used this to try and fix this error, doesn't fix
    "broccoli-static-compiler": "^0.2.2",
},

ERROR Summary:

  - broccoliBuilderErrorStack: Error: Minimum builderFeatures required: { persistentOutputFlag: true }
    at LessCompiler.Plugin._checkBuilderFeatures (<path>/node_modules/broccoli-less-single/node_modules/broccoli-plugin/index.js:62:11)
    at LessCompiler.Plugin.__broccoliGetInfo__ (<path>/node_modules/broccoli-less-single/node_modules/broccoli-plugin/index.js:45:8)
    at getPluginName (<path>/node_modules/broccoli-builder/lib/builder.js:291:23)
    at new Node (<path>/node_modules/broccoli-builder/lib/builder.js:260:11)
    at readAndReturnNodeFor (<path>/node_modules/broccoli-builder/lib/builder.js:112:16)
    at <path>/node_modules/broccoli-builder/lib/builder.js:151:24
    at tryCatch (<path>/node_modules/broccoli-builder/node_modules/rsvp/dist/rsvp.js:525:12)
    at invokeCallback (<path>/node_modules/broccoli-builder/node_modules/rsvp/dist/rsvp.js:538:13)
    at <path>/node_modules/broccoli-builder/node_modules/rsvp/dist/rsvp.js:606:14
    at flush (<path>/node_modules/broccoli-builder/node_modules/rsvp/dist/rsvp.js:2415:5)
    at process._tickCallback (internal/process/next_tick.js:61:11)

  - codeFrame: Minimum builderFeatures required: { persistentOutputFlag: true }
  - errorMessage: Build Canceled: Broccoli Builder ran into an error with `BroccoliMergeTrees` plugin. 💥
Minimum builderFeatures required: { persistentOutputFlag: true }
  - errorType: Build Error
  - location:
    - column: [undefined]
    - file: [undefined]
    - line: [undefined]
    - treeDir: [undefined]
  - message: Build Canceled: Broccoli Builder ran into an error with `BroccoliMergeTrees` plugin. 💥
Minimum builderFeatures required: { persistentOutputFlag: true }
  - name: Error
  - nodeAnnotation: BroccoliMergeTrees
  - nodeName: BroccoliMergeTrees
  - originalErrorMessage: Minimum builderFeatures required: { persistentOutputFlag: true }
  - stack: Error: Minimum builderFeatures required: { persistentOutputFlag: true }
    at LessCompiler.Plugin._checkBuilderFeatures (<path>/node_modules/broccoli-less-single/node_modules/broccoli-plugin/index.js:62:11)
    at LessCompiler.Plugin.__broccoliGetInfo__ (<path>/node_modules/broccoli-less-single/node_modules/broccoli-plugin/index.js:45:8)
    at getPluginName (<path>/node_modules/broccoli-builder/lib/builder.js:291:23)
    at new Node (<path>/node_modules/broccoli-builder/lib/builder.js:260:11)
    at readAndReturnNodeFor (<path>/node_modules/broccoli-builder/lib/builder.js:112:16)
    at <path>/node_modules/broccoli-builder/lib/builder.js:151:24
    at tryCatch (<path>/node_modules/broccoli-builder/node_modules/rsvp/dist/rsvp.js:525:12)
    at invokeCallback (<path>/node_modules/broccoli-builder/node_modules/rsvp/dist/rsvp.js:538:13)
    at <path>/node_modules/broccoli-builder/node_modules/rsvp/dist/rsvp.js:606:14
    at flush (<path>/node_modules/broccoli-builder/node_modules/rsvp/dist/rsvp.js:2415:5)
    at process._tickCallback (internal/process/next_tick.js:61:11

Can someone help me out here with some pointers?

After going through our what we're doing in our postProcess hook -- checking for a throwOnError option and then reducing the severity count from a report result's messages to a truthy number if we detect an error -- it seems like it would be pretty trivial to also check for throwOnWarn (or any arbitrary threshold, but perhaps that's another discussion 😄), reduce message severity into a raw sum, and then act accordingly from there.

(Side note: We're actually iterating through messages before checking whether or not the user has even set throwOnError, but #44 addresses that as well)

Using an up-to-date eslint will solve some of my problems.

There's a current issue with ESLint @2.3.0 that seems to be causing a lot of problems in consuming libraries using it alongside babel-eslint.

I mentioned it on an eslint-config-ember issue a few weeks ago, but I didn't quite realize the extent of what it would affect. In short -- even after trying to hack together custom dependencies locally -- ember-cli-eslint currently seems to be unusable due to deeper dependencies such as broccoli-lint-eslint using eslint-2.3.0.

After digging in to ember-cli-eslint, eslint-config-ember, eslint-config-nightmare-mode and broccoli-lint-eslint, I'd like to propose a path forward that includes pinning everything using eslint to eslint@2.2.0 until there's a resolution to the issue above -- or until we can jump ahead to ESLint 2.4.0 (which seems to be where a lot of the chatter is babel-eslint is leaning).

If this sounds reasonable, I'd certainly be willing to help out with pulling some of the strings that that might require.

Now that ESLint 3.0 has been released, it would be a nice upgrade to get into broccoli-lint-eslint soon.

Potential Blockers:

• ESLint Node support should align with that of Ember CLI's

Useful links:

• Release notes
• Migration guide

It appears that throwOnError is a property on internalOptions but there does not appear to be any way to set that. Am I missing something?

Right now we're currently using the 1.1.1 version of broccoli-lint-eslint (via ember-cli-eslint), which pulls in eslint 1.x version

After a recent nombom, using 1.6.0 of broccoli-lint-eslint will pull in 2.x eslint, which breaks a bunch of stuff in our project (as it should since it is a major version change).

Wouldn't it make sense to have broccoli-lint-eslint's versioning change from 1.x to 2.x since it includes a breaking change (2.x eslint)?

I'm playing around with to using broccoli-lint-eslint @ 2.0.0 inside of ember-cli-eslint, and the installed package only includes these:

CHANGELOG.md
LICENSE
README.md
conf/
lib/
node_modules/
package.json

This causes require('broccoli-lint-eslint') to fail with a "module not found" error, as main in package.json is pointing to build/index.js. It looks like there's a prepublish hook in our package.json that should be in charge of creating build, so I'm not yet sure what the cause might be.

Possible to get a new release? It's been nearly a year, and there's an ESLint 5 rule I'd like to use. Or is there another way to use the latest eslint?

There are some new esnext patterns that require a lot of finesse in order to make ESLint 2 happy. For example, async arrow functions

async function renderChapters(urls) {
  await Promise.all(urls.map(getJSON).map(async j => addToPage((await j).html)));
}

Are there plans to upgrade this addon? Should I make a new one?

I haven't used Ember for the last 8 or so months, which means that I'm taking a lot of my free time to manage changes on projects like this.

I would like a keen maintainer who can work in times when I am busy.

Apply here.

While developing ember-cli/ember-cli-eslint#41, I initially bumped the broccoli-lint-eslint version to 2.0.1, just to see if that changed anything. I noticed that any files within the tests/ directory of the Ember app I was testing against were no longer using the .eslintrc file under tests/.eslintrc to overwrite the configuration provided by the config file in the root of the app. So, certain files that were passing before were failing after updating this dependency, and passed again after reverting to the original version.

Just updated to the latest ember cli, and got this error :
Invalid regular expression: /()?build()?$/: Unterminated group

It come from this line :

var BUILD_DIR_REGEX = new RegExp('(' + path.sep + ')?build(' + path.sep + ')?$');

path.sep needs to be escaped as on windows it is ''

I fixed that like this :

var BUILD_DIR_REGEX = new RegExp('(\\' + path.sep + ')?build(\\' + path.sep + ')?$');

Should I create a pull request, or can someone directly fix that ?

Thanks !

It's pretty clear that there are some issues with the caching, namely that configuration changes don't invalidate the cache. A number of issues have come up with that as the root problem:

• ember-cli-eslint #11
• ember-cli-eslnit #118

I wanted to make an issue here as a reminder about this and a place to start gathering information for putting together a fix.

ESLint does provide a way to programmatically get the ESLint configuration for a particular file, namely the getConfigForFile function. Maybe we can use this information as part of the caching mechanism? My concern would be that this would be a pretty slow approach, but I don't know how poor the performance would actually be. I do feel like this might be a good approach because it would take any changes to the configuration into account, whether it's a change to a config file or adding things to an eslintignore, and would be robust going forward as long as their Node API does not change.