Custom environments wouldn't solve this problem for you, they still would only be applied at either a directory or file level (with inline comments). There would still be no way to say at the top level that one environment applies to files with .js and another for .jsx.
On Sat, Feb 28, 2015 at 12:58 PM, Glen Mailer <[email protected]> wrote: > Unfortunately, the various types of files I have don't really fit into a > nice tree model :( > > The plugin-provided-environemnts feature described in > https://github.com/eslint/eslint/issues/1130 seems like it would do what > I wanted. > > I'm up for trying to put together a PR - should I start putting together a > prototype, or is there some more discussion about how it should work that > needs to happen first? > > Cheers for the speedy responses! > Glen > > On Friday, 27 February 2015 19:31:07 UTC, Nicholas Zakas wrote: >> >> Hi Glen, >> >> There's not a way to interpret different files with different rules. You >> can, however, put those files into separate directories and apply different >> rules to each directory using .eslintrc files. >> >> -N >> >> On Fri, Feb 27, 2015 at 5:54 AM, Glen Mailer <[email protected]> wrote: >> >>> Hello, >>> >>> I've been looking for a way to combine linting and JSX / ES6 files >>> within a large project. >>> >>> The project has a number of separate applications within it, where each >>> has it's own package.json - but the linting rules are applied globally. >>> >>> We have eslint set up to lint all *.js files, and jsxhint does all *.jsx >>> files. >>> >>> I've been trying out the preview release of https://github.com/babel/ >>> babel-eslint just now - and it looks like this makes eslint's ES6 >>> support wide enough to be the one linter that can do our whole codebase \o/. >>> >>> However, there's a slight complication. We want to have a single set of >>> rules across all projects - but there are a few different contexts that our >>> code runs in: >>> >>> 1. Non-ES6 JS for node >>> 2. Babel-compiled ES6 JS for node >>> 3. Non-ES6 JS for the browser >>> 4. Babel-compiled JSX for the browser >>> >>> The reason these different contexts exist is due to the way the build >>> tools are set up, ES6 features are opt-in by naming the file *.jsx >>> >>> Ideally I'd want to configure use of ES6 features to be an error in *.js >>> files, but allowed in *.jsx files - but JSX elements to only be allowed in >>> client-side code. >>> >>> Is there a way to get eslint to interpret different files across the >>> same project with different rules? >>> >>> I hope that makes sense - I've tried to provide as much context for the >>> setup as I could! >>> >>> >>> Cheers >>> >>> Glen >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "ESLint" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> >> ______________________________ >> Nicholas C. Zakas >> @slicknet >> >> Author, Professional JavaScript for Web Developers >> Buy it at Amazon.com: http://www.amazon.com/Professional-JavaScript- >> Developers-Nicholas-Zakas/dp/1118026691/ref=sr_1_3 >> > -- > You received this message because you are subscribed to the Google Groups > "ESLint" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- ______________________________ Nicholas C. Zakas @slicknet Author, Professional JavaScript for Web Developers Buy it at Amazon.com: http://www.amazon.com/Professional-JavaScript-Developers-Nicholas-Zakas/dp/1118026691/ref=sr_1_3 -- You received this message because you are subscribed to the Google Groups "ESLint" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
