Using src from the parent folder of gulpfile.js will not be linted

For a Meteor project we have to keep the gulpfile.js and node_modules in a folder that is not visible to meteor otherwise it will compile them. This means putting gulpfile.js into a dot subfolder like .gulp which is what https://github.com/bbmoz/meteor-gulp/ does. The gulpfile it generates looks something like this.

https://github.com/bbmoz/meteor-gulp/blob/master/plugin/gulpfile.temp

Their example uses jshint and jscs but I’d rather use eslint because it’s a bit easier to configure for Angular and ES6. However when the ./../** ... globs get passed to eslint it does not get processed. I have verified that the files will match the glob if I use gulp-print to print out the file list. My current workaround is to reorganize the project such that gulpfile is in the parent folder and my meteor is in a sub folder.

[adametry]

Try adding warnFileIgnored:true to your gulp-eslint config. If you receive a bunch of ignore warnings let me know and I’ll dig into why the linter might give mixed messages (gulp-eslint uses eslint’s isPathIgnored to avoid linting .eslintignore’d files).

[shinnn]

├ project (cwd)
│ ├ gulpfile.js
│ └ package.json 
│
└ script.js 

package.json:

{
  "name": "test",
  "private": true,
  "devDependencies": {
    "gulp": "gulpjs/gulp#d8f5c90a0622d19ef1943a2a3d02dc50e3c853e7",
    "gulp-eslint": "^3.0.1"
  }
}

gulpfile.js:

'use strict';
const gulp = require('gulp');
const eslint = require('gulp-eslint');

gulp.task('default', () => {
  return gulp.src('../script.js')
  .pipe(eslint({
    useEslintrc: false,
    rules: {
      camelcase: 'error'
    }
  }))
  .pipe(eslint.format());
});

script.js:

a_b = c

$ node -v
v6.3.0

$ npm -v
3.10.5

$ node node_modules/gulp/bin/gulp.js
[03:22:50] Using gulpfile ~/test/project/gulpfile.js
[03:22:50] Starting 'default'...
[03:22:50] 
/Users/Shinnosuke/test/script.js
  1:1  error  Identifier 'a_b' is not in camel case  camelcase

✖ 1 problem (1 error, 0 warnings)

[03:22:50] Finished 'default' after 75 ms

This issue seems to be fixed in the latest version.