[Solved enough once Meteor 1.3.3 released] ESLint for Meteor 1.3 "modules" and strict mode

help
1

tl;dr: I think Meteor 1.3 modules don’t enforce strict mode, and my practices confuse ESLint.

Details

I like strict mode and I’m pretty sure Meteor doesn’t run in strict mode, even with Meteor 1.3. So I place 'use strict'; on the top of all my files. I don’t think I should have to do this as Meteor 1.3 claim ES2015 modules, and ES2015 Modules imply strict mode.

I’ve recently upgraded to Meteor 1.3 following the Meteor Guide’s structure recommendation, and moved a bunch of code to my /imports folder using syntax like import FunClass from '/imports/classes/fun-class';

I’m Configuring ESLint with an .eslintrc.js like:

'use strict';
module.exports = {
  ...
  parserOptions: { 
    ecmaVersion: 6,
    sourceType: 'module',
    ecmaFeatures: {
      impliedStrict: false // Doesn't actually help
    }
  },
  rules: {
    strict:[
      'error',
      'gobal'
    ],
    ..
  }
  ...
}

For a file like

'use strict';
import { Meteor } from 'meteor/meteor';

ESLint reports

‘use strict’ is unnecessary inside of modules. (strict)

When I change to sourceType: 'script' ESLint reports:

Parsing error: ‘import’ and ‘export’ may appear only with 'sourceType: module

For now I’m leaving my .eslintrc.js with sourceType: 'module' and removing the strict rule, but this doesn’t feel great because:

  1. I could easily forget to place a 'use strict'; on the top of my files
  2. Meteor isn’t formally run in modules which now ESLint expects

Questions
Am I misunderstanding something? Do we know of any workarounds for ESLint? Should ESLint be extended? Should Meteor be patched per the issue I opened?

2

Try this

3

@trajano - Thanks for the suggestion, though that doesn’t seem to work for my use case. You did open my eyes to a couple eslint plugins though (meteor & import) which I plan to integrate into my .eslintrc.js :slight_smile:

Details
I forked and slightly modified for simpler test case at https://github.com/AnthonyAstige/meteor-boilerplate/blob/angular/.eslintrc.json and still get the errors:

‘use strict’ is unnecessary inside of modules. (strict)

It makes sense that the Angular .eslintrc.json doesn’t help me here, as it also has "sourceType": "module" and there’s nothing in there I see that would modify how 'use strict'; is interpreted.

4

I was just thinking about that statement. AFAIK, If you’re using ES6 you’re implicitly in strict mode, hence you don’t and shouldn’t need to put in 'use strict';

So if you don’t want that warning, you can ignore the strict rule and use sourceType: 'module'. However, personally I would just avoid it since it is framework level, not application level.

BTW there’s master branch that does not use AngularJS nor their linters.

5

Meteor/ES6

Yeah, I think that’s how Meteor should work, but it doesn’t appear Meteor enables strict mode:

  1. I’ve reproduced the errant behavior
  2. I’ve reported a bug

ESLint

Yeah for now I’m using sourceType: 'module' and have the ESLint strict rule off. However because of the Meteor/ES6 problem noted above I’m still putting 'use strict'; on the top of all my files. The downside being I don’t have a linter to warn me if I forget to add it to one of my files.

6

I’ve posted an issue to ESLint @ Need to parse ES6 modules as not implicitly strict in case this can be resolved there.

7

I’ve posted an issue to eslint-plugin-meteor @ Enforce strict mode on ES6 modules when not implicit due to transpiling issue as ESLint isn’t going to solve this for us.

8

I don’t think it will be a linting issue. If Meteor is not enabling strict mode (as you have noted it’s not being put on the output JS files) then it’s a meteor issue rather than a Linting issue.

9

I agree it’s a Meteor issue, however I don’t think Meteor core will fix it very quickly. I think this problem has been around since Meteor 1.2 introduced ecmascript which was released in September 2015. If strict mode is suddenly enabled by default in modules, it could break a lot of people’s code who expect strict mode to be off. This feels like a breaking change that would require a major release, and who knows when Meteor 2.0 will be released.

That said, I think a linter could enforce my band-aid solution of adding 'use strict'; to the top of all files until then.

A better solution would be, if possible, making an optional package that hooks into the ecmascript package and turns on strict mode in modules. I have no idea off hand if that’s possible.

10

I think if you use the eslint rules from airbnb and meteor you should have enough coverage that you don’t need to explicitly enforce strict mode on the browser level. The only thing you need to concern is basically the use of arguments.callee, but if you do use that you need to make sure strict mode is off anyway.

11

I have my own custom eslint rules, probably even more restrictive than airbnb & meteor. You’re right eslint will probably catch a lot of problems before strict mode matters, but I don’t have confidence it would catch everything that strict mode would (it’s very hard to prove a negative).

1 Like
12

Understood, I still think you’d hit a wall on this one.

If Meteor decides to implicity add "use strict"; then some library code that others would include that is not in their control which uses arguments.callee to get the function name and do some reflection logic on it will fail.

Linters on the other hand are doing the right thing in that they are saying “use strict” is not needed.

Anyway good luck.

13

Yeah sounds like we’re on the same page RE: Meteor & ESLint. I think I know where to go from here once I hear back more from Meteor.

Thanks for the input and discussing this with me.

14

Looks like a work-around with .babelrc is coming in Meteor 1.3.3 :grin: