Eslint doubles build times


#1

Before adding any linters, my build time averages 17 seconds for Meteor 1.3 on Windows.
Installing eslint-plugin-react has no effect on the build times.
Installing eslint-plugin-meteor almost doubles my build times to about 32 seconds.
Installing esling-config-airbnb also increases my build times to 32 seconds.
Installing all 3 increases my build times on average to 40 seconds.

Any suggestions to improve performance?


Code Style Article
#2

It sounds like you may have made eslint and related plugins a part of your dependency chain. If this is the case, maybe install them using something like meteor npm install eslint-plugin-meteor --save-dev.

If you’re not sure show us your package.json.


#3

That is how I was installing (based on the guide).

I just performed a simple test. I created a new meteor app. The new blank app takes 3 seconds to build and has 4,558 files. I run meteor npm install eslint-plugin-meteor --save-dev
Afterwards, it takes 8 seconds to build and contains 15,174 files.

My current project has 11,116 files and takes 12 seconds to build on my fastest computer. After installing eslint-plugin-meteor, the build time jumps to 23 seconds and the file count is 25,896.

I’ve only tested on Windows. Is the build time proportional to the file count? Since I’m using Atom, would it be better to install the plugins globally with npm?

Here is my package.json after install eslint-plugin-meteor:

{
  "name": "fanx",
  "private": true,
  "scripts": {
    "start": "meteor run"
  },
  "dependencies": {
    "material-ui": "^0.15.0-beta.2",
    "meteor-node-stubs": "~0.2.0",
    "react": "^15.0.2",
    "react-addons-pure-render-mixin": "^15.0.2",
    "react-dom": "^15.0.2",
    "react-mounter": "^1.2.0",
    "react-tap-event-plugin": "^1.0.0"
  },
  "devDependencies": {
    "eslint": "^2.10.2",
    "eslint-plugin-meteor": "^3.5.2"
  }
}

#4

I installed Ubunto in VirtualBox on my laptop. The build time for my project is 13 seconds. After installing eslint-plugin-meteor the build time stayed at 13 seconds.

I guess this is a bug with only the Windows version of Meteor.

Anyone have a work-around for Windows?


#5

I haven’t worked with npm/meteor on windrows, but as a workaround, can you try moving eslint from your project to a global level?

Something like npm r eslint --save then npm i eslint -g.


#6

Thanks the global approach worked. No increase in build time. I cut my build time from over 40 seconds to 16.1.

Here’s my eslintrc.json file. I’m not sure if it is set up correctly, but it appears to work. I had to enable the global option under the Atom eslint settings.

{
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module"
  },
  "plugins": [
    "meteor"
  ],
  "extends": [
    "airbnb",
    "plugin:meteor/recommended"
  ],
  "rules": {
    "react/jsx-boolean-value": [0],
    "func-names": [0],
    "no-underscore-dangle": [0],
    "no-use-before-define": [0],
    "meteor/eventmap-params": [
      2,
      {
        "eventParamName": "event",
        "templateInstanceParamName": "instance"
      }
    ],
    "meteor/template-names": [0],
    "import/no-unresolved": [
      2, { "ignore": ["^meteor/"] }
    ]
  }
}

#7

Here’s the command I used for the global npm install:

npm install -g eslint-config-airbnb eslint-plugin-import eslint-plugin-meteor eslint-plugin-react eslint-plugin-jsx-a11y eslint


#8

Interesting I wonder if someone from MDG would know why.


#9

Wouldn’t it be much better not to have to install anything related to ESLint into the app (even as a “devDependency”)?

I think ESLint is better used at the editor / IDE level, so that errors are pointed out in real time as you code in the editor and you can then fix them then and there.

I wrote about how easy it was to add ESLint support (which also comes with CSSLint, TSLint, and CoffeeLint) to an existing Visual Studio 2015 installation:


#10

Agree.
The global approach doesn’t add to your app. Although, you still have to add an .eslintrc.json file to your project to specify application specific plugins, options and rules.


#11

Personally, I am on the side that almost everything you need for your app development should remain with the app for a a few reasons:

  1. you control the tool versions so you can …
  2. make things predicable in continuous integration which …
  3. gives a basis for developers to set up their development environment which …
  4. allows the project to developed with less development setup which …
  5. allows developers to clone different copies and allow for multiple branches of work locally which also means …
  6. they can help other projects if necessary.