Code Style Article


#1

This is the comment thread for the Code Style article in the Meteor Guide.

Read the article: http://guide.meteor.com/code-style.html

The comment thread for each article appears at the very bottom of the page. Use this thread to post:

  • Interesting articles related to the content
  • New ways to do things that aren’t covered in the Guide
  • Suggestions for Guide improvements

Or anything else related to this topic that people could find useful!


#2

I am trying to set up ESLint for Meteor and IntelliJ IDEA (i.e. WebStorm). I can run ESLint with the Meteor command just fine following the directions. My issue is with IntelliJ IDEA. First, I suggest that you make it explicit that you need to install ESLint a second time for IntelliJ, and to do this you need to install node/npm globally, plus (at least in my case), you need to run the following command so that IntelliJ can find the eslint airbnb package:

npm install -g eslint-config-airbnb

Once I got through all this, I wondered why I couldn’t configure IntelliJ to use the version of node/npm installed with Meteor. After some searching, I found the path to the Meteor version of node here:

.meteor/packages/meteor-tool/1.3.1/mt-os.osx.x86_64/dev_bundle/bin

However, I could not find the eslint package anywhere in the ~/.meteor directory, or in my app’s .meteor directory.

If someone could figure out the correct configuration for IntelliJ to use Meteor’s version of node and libraries, I think that would be an improvement.


#3

Hi @philipmjohnson,

Is there any way to point Webstorm at the local npm packages? That would be ideal (allows different projects to use different plugins+versions from npm without having to install them all globally).

If you figure it out, please please send a PR to the guide!


#4

I just realized that as of 1.3 there’s a project-specific node_modules/ directory…

It looks like configuring IntelliJ to use Meteor’s node installation (as opposed to the global one) is quite simple: point IntelliJ’s project-specific preferences at the node binary installed in ~/.meteor, and at <project>/node_modules/eslint. See the following image:

So far, so good. I don’t want to submit a PR until I’ve used this a bit more. :slight_smile:


#5

I’m wondering if the Code Style documentation should also include a recommendation for JavaScript documentation, I believe Meteor core uses JSDoc?


#6

I’m thinking eslint shouldn’t give errors when following the guide, eg after creating a new default app. Or to be more precise – I was expecting it not to give errors, and it did.

Eg running:

meteor create myapp
meteor npm install
meteor npm install --save-dev eslint eslint-plugin-react eslint-plugin-meteor eslint-config-airbnb

and populating scripts and eslintConfig as above in package.json, then "meteor npm run lint" gave me:

> myapp@ lint /opt/www/sites/me/myapp
> eslint .


/opt/www/sites/me/myapp/client/main.js
   1:26  error  Unable to resolve path to module 'meteor/templating'    import/no-unresolved
   2:29  error  Unable to resolve path to module 'meteor/reactive-var'  import/no-unresolved
  18:25  error  Invalid parameter name, use "templateInstance" instead  meteor/eventmap-params

/opt/www/sites/me/myapp/server/main.js
  1:24  error  Unable to resolve path to module 'meteor/meteor'  import/no-unresolved

✖ 4 problems (4 errors, 0 warnings)

I eventually made it quiet with rules in package.json:

"rules": {
  "meteor/eventmap-params": [
    2, { "templateInstanceParamName": "instance" }
  ],
  "import/no-unresolved": [
    2, { "ignore": ["^meteor/"] }
  ]
}

Should that be included or noted?


Linting issue with imports
#7

Yeah we should definitely either fix this or mention it in the guide. If you have a moment, please submit a PR to add your config to the guide!


#8

This type of import works in Meteor

import xxx from ‘/client/xxx’

but it is shown as import/no-unresolved when linting. This can be solved using ignore rule in eslintrc. Is there any other way to satisfy this rule instead of ignoring it.


#9

@suhaila yeah check the bottom of this section, it tells you how to ignore only meteor/*: http://guide.meteor.com/code-style.html#eslint-installing


#10

Perhaps we can add something about meteor lint and use something like https://atmospherejs.com/dburles/eslint to perform the linting for us. I say “something like” as I get Error: No os unibuild for null! when using eslint as noted by https://github.com/meteor/meteor/issues/6843#issuecomment-215804381


#11

Instead of defining the ignores yourself I recommend adding https://github.com/clayne11/eslint-import-resolver-meteor this will reduce your rules to {}

Here’s the relevant PR https://github.com/meteor/guide/pull/434 perhaps someone can take the time to update the todo app?

However if you need an example of this, I have it on https://github.com/trajano/meteor-boilerplate/blob/meteor-skeleton-1.0.3/.eslintrc.json

The angular branch of my boilerplate has an unstyled todo app written in AngularJS1 since angular1 doesn’t seem to get enough love here :slight_smile:


#12

The editor integration section for linter-eslint seems to be missing a step for the Atom integration (at least with respect to React). It doesn’t like the tags in your render() code:

Parsing error: Unexpected token


#13

This is what I did to make it work with vim, meteor and lint.

Get all the npm packages, in my case I need to use the same packages for vim, so I installed them globally.

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

Edit the packages.json with the lint shortcut.

{
    ....
    "scripts": {
      "start": "meteor run",
      "lint": "eslint .",
      "pretest": "npm run lint --silent"
    },
    ...
}

Create the .eslintrc with this settings.

{
	"plugins": [
	    "meteor"
	],
	"extends": [
	    "airbnb",
	    "plugin:meteor/recommended"
	],
	"rules": {
	    "meteor/eventmap-params": [
	        2, { "templateInstanceParamName": "instance" }
	    ],
	    "import/no-unresolved": [
	        2, { "ignore": ["^meteor/"] }
	    ],
	    // enable this._variable (used many times to refer the this._id)
	    "no-underscore-dangle": ["error", { "allowAfterThis": true }],
	    // my indentation is four spaces (sorry, its better for me)
	    "indent": ["error", 4],
	    // meteor uses globals and includes a lot
	    "no-unused-vars": 0,
            // enable console
            "no-console": 0,
	},
	"env": {
	    "meteor": true,
	    "node": true,
	    "browser": true
	},
	// ignore some undeclared global variables and methods
	// used by Meteor
	"globals": {
	    "describe": false,
	    "it": false,
	    "before": false,
	    "beforeEach": false,
	    "after": false,
	    "afterEach": false
	}
}

Install the scrooloose/syntastic Vundle in Vim.

" Lint
Plugin 'scrooloose/syntastic'
let g:syntastic_javascript_checkers = ['eslint']
let g:syntastic_check_on_open=1

Now meteor and vim are using the same .eslinrc configuration file. I can lint with Meteor and also get the lint error report from vim.


#14

How do you prevent it from scanning .meteor, node_modules and packages?


#15

I think the guide should include a little more details of how incredibly helpful ESLint can be for React. It provides much more than style and typo checking. I’ve found it very helpful to improving my React programming. For example: warning a component should be a pure render function instead of a class and when function binding can cause inefficient garbage collection.

A few other notes:

  1. In Windows, you should install the NPM plugins globally. Otherwise, you can double your build times.
  2. In Atom, I only had to install ESLint. It automatically installed the dependencies and I don’t think Babel is necessary.
  3. In Atom, you need to set the ESLint global installation flag if the you install the NPM plugins globally.
  4. For react, you need to set up parser options in your eslintrc.json file for ecmaVersion and sourceType.

#16

Is there any evidence or reason to this? Or are you talking specifically about meteor build?


#17

After I installed the ESLint plugins locally, Meteor went from 16 to 40 seconds to restart any time I saved changes. Switching to global lowered my build times back to 16 seconds. This is only on Windows. On Ubuntu, the local install had no effect.
Here’s a thread I posted discussing it.


#18

in Code style doc you are writing

Collections should be named as a plural noun, in PascalCase. The name of the collection in the database (the first argument to the collection constructor) should be the same as the name of the JavaScript symbol.

but users collection is in db lowercase, how can I change it ?
Thanks
Best Regards


#19

I just want to second this piece of advice and thank @trajano for it! This is the key to getting the false positive errors on absolute paths to go away.

I’ve seen many posts where people are indicating that absolute paths in import statements weren’t working. They work. They are interpreted by Meteor as paths relative to the project root directory. But without this resolver, ESLint is telling everyone that they are errors, and people are confusing that with Meteor not supporting it. I dug into Meteor’s module code and found that not only are the absolute paths supported, but the very first test verifies that they work. This is explicit support.

To expand on the installation of this, it is an NPM module. So add it to the “npm install” command recommended in the article as follows…

meteor npm install --save-dev eslint-config-airbnb eslint-plugin-import eslint-import-resolver-meteor eslint-plugin-meteor eslint-plugin-react eslint-plugin-jsx-a11y eslint

Of course, if you already have the others just…

meteor npm install --save-dev eslint-import-resolver-meteor

Then add the following to your .eslintrc.json file

  "settings": {
    "import/resolver": "meteor"
  },

#20

Can someone send a PR to add this stuff to the guide article?