Code Style Article

Your wish is my command (today)! Done.

With the advent of conditional and nested import support in Meteor 1.3.3 and up, ESLint “breaks” if you make use of a conditional or nested import within a module.

To expand on that, if you use code like

if (this.isServer) {
   import { ServerSauce } from './server/serverOnlyCode';
}

ESLint will give a syntax error similar to the following and stop processing the file.

272:7  error  Parsing error: 'import' and 'export' may only appear at the top level

Luckily, the maintainers of babel-eslint, an alternative parser for ESLint, accepted a PR to implement an option that allows this syntax.

To get ESLint to work with nested imports and exports (yes, have not yet seen a use-case for them but conditional exports work too with Ben’s changes), just run

$meteor npm install --save-dev babel-eslint

to get the latest version of babel-eslint (>= 6.1.0) and add the following into your ESLint configuration in package.json or .eslintrc.json:

  "parser": "babel-eslint",
  "parserOptions": {
    "allowImportExportEverywhere": true
  },

I’ll create a guide PR to show this there too.

3 Likes

You can use

const ServerSauce = require('./server/serverOnlyCode').ServerSauce

Without having to update eslint.

As for a use case for conditional loads, I use it as part of my gulpfile.js to prevent the actual gulp file from being loaded in Meteor

if (typeof Meteor === typeof undefined) {
  // eslint-disable-next-line vars-on-top, no-var
  var r = require
  r('./.gulp/gulpfile')
}

Of course, require can still be used, but the point of the new support is to get rid of the split personality aspect of using two different module systems in one file. Since Ben implemented it as an NPM module, reify, a means is now available to the whole NPM community to stop using require throughout their file, not just at the top level.

My comment on the use-case was concerning conditional exports, not imports. I believe they were included mostly to maintain import <> export symmetry. I haven’t yet dug into experimenting with conditional exports other than to verify that something with a conditional export does in fact build.

2 Likes

+1 for JSDoc recommendation.

You could even enforce it with ESLint like so,

in eslintConfig

...
"valid-jsdoc": "error",
  "require-jsdoc": [
    "error",
    {
      "require": {
        "FunctionDeclaration": true,
        "MethodDefinition": true,
        "ClassDeclaration": true
      }
    }
  ],
...

I don’t think though enforcing JSDoc would make for a nice experience for those who are just starting out with Meteor. ‘Gentle suggestions’ for beginners and ‘Highly recommended’ for large projects with multiple devs.

1 Like

Haha, this makes me think of some evilly-grinning lead dev :grin:

1 Like

@tmeasday

I started using the style recommendations in this guide several weeks ago and while investigating a high cpu usage issue with Webstorm (2016.2) today, I saw a new version of eslint was available (3.x, while I was on 2.x).

I couldn’t figure out why running npm update wouldn’t update to eslint 3.x, so I ran npm uninstall on all the eslint-related packages I had, and simply attempted to reinstall them fresh.

After doing this I was warned about dependency issues eslint-airbnb-config has with eslint:

npm WARN eslint-config-airbnb@9.0.1 requires a peer of eslint-plugin-jsx-a11y@^1.2.0 but none was installed.
npm WARN eslint-plugin-jsx-a11y@2.0.1 requires a peer of eslint@^2.10.2 || 3.x but none was installed.

I found that eslint-airbnb-config is not yet compatible with the new 3.x version of eslint, released earlier this month.

Until Airbnb updates their config for 3.x support, I think you have to specify the latest compatible version of eslint during your install, along with a version specification for eslint-plugin-jsx-a11y, whose latest version 2.0.1 otherwise requires at least eslint 2.10.x.

This appears to do the trick for me:

meteor npm install --save-dev babel-eslint eslint-config-airbnb eslint-plugin-import eslint-plugin-meteor eslint-plugin-react eslint-plugin-jsx-a11y@1.2.0 eslint-import-resolver-meteor eslint@2.9.0

2 Likes

ESLint 3.x is a breaking change and specifically broke compatibility with Node < 4.0. Therefore, it should not be used with Meteor < 1.4.

The reason running npm update wouldn’t perform the update to ESLint 3.x is because ESLint 3.x’s package.json file correctly specifies that it requires Node >= 4.x. NPM saw that you weren’t running that Node and, very correctly, chose not to do the update.

I think there are multiple plugins that aren’t yet compatible with ESLint 3.x. Best to hold off.

If you choose to push the edge, you’ll have to either run Meteor 1.4 beta or stop using Meteor to run npm. I advise against that latter choice which mixes build systems. I have encountered a lot of problems with different versions of NPM / Node operating on the same node_modules directory. As a matter of policy, I wipe out and rebuild node_modules every time I change NPM / Node versions. That gets rid of a lot of flakiness.

1 Like

It seems that the eslint configuration is broken yet again. Running it on a fresh project turns up these issues:

error ‘meteor’ should be listed in the project’s dependencies. Run ‘npm i -S meteor’ to add it import/no-extraneous-dependencies
error Missing file extension for “meteor/check” import/extensions
error Do not import modules using an absolute path import/no-absolute-path

Does anyone have a working package.json file that can just report real lint errors on a fresh application?

YMMV of course, but here are the dev dependencies I’m using in a new (1.4.2.3) project:

"devDependencies": {
    "babel-eslint": "^6.1.2",
    "eslint": "^3.5.0",
    "eslint-config-airbnb": "^11.1.0",
    "eslint-import-resolver-meteor": "^0.3.3",
    "eslint-plugin-import": "^1.15.0",
    "eslint-plugin-jsx-a11y": "^2.2.2",
    "eslint-plugin-meteor": "^4.0.0",
    "eslint-plugin-react": "^6.2.2",
    "nightmare-meteor": "^2.4.21",
    "shell-source": "^1.1.0",
    "shelljs": "^0.7.4"
  }

That helped a bit but what really did the trick was adding the following in package.json

"eslintConfig": {
...
"settings": {
            "import/resolver": "meteor",
            "import/core-modules": [
                "meteor/meteor",
                "meteor/check",
                "meteor/react-meteor-data",
                "meteor/random",
                "meteor/mongo",
                "meteor/accounts-base",
                "meteor/practicalmeteor:chai",
                "meteor/aldeed:simple-schema"
            ]
        },
...
}

By adding each import that was failing to the core modules it stopped complaining with:

error 'meteor' should be listed in the project's dependencies. Run 'npm i -S meteor' to add it import/no-extraneous-dependencies

This is a similar solution to @joltmans which is a bit more dynamic as it got annoying to add every package.
This will obviously only work if your configuration is in a js file.

Is there a way to include more options or my own skeleton structure to meteor create? I’d like to include a standard .eslintrc when I create new projects.

In the Easy to Read Code section there is this snippet which is misleading about the question at hand (braces or not for single-line statements).

// This code is misleading because it looks like both statements
// are inside the conditional.
if (condition)
  firstStatement();
  secondStatement();

It is misleading because it does not put the secondStatement() aligned with the ‘if’. Had it done so and perhaps put a blank line then it would be more correctly showing that there actually IS a way to do this single line statement without braces and still be readable and non-confusing. The problem that makes the code confusing is that coders often jam the bits too close together vertically. The braces example in this topic is good because it does not do that, not just that it provides begin-end pairs.

// This code is NOT misleading because it does not look like both statements
// are inside the conditional.
if (condition)
  firstStatement();

secondStatement(); 

That said, it is often best to use braces for clarity.

When i try to use @babel/eslint-parser (new babel-eslint) with my vue project to avoid the import error, i got the following message for all .vue file:

This experimental syntax requires enabling one of the following parser plugin(s): "jsx", "flow", "typescript".

After 5 years, is there a way to use eslint and avoid the import error ? or is it possible to @babel/eslint-parser with the vue project.

Thanks,

My package.json:

"devDependencies": {
    "@babel/core": "^7.17.8",
    "@babel/eslint-parser": "^7.17.0",
    "babel-plugin-istanbul": "^6.1.1",
    "chai": "^4.3.6",
    "chromedriver": "^89.0.0",
    "codecov": "^3.8.3",
    "cypress": "^6.9.1",
    "eslint": "^8.12.0",
    "eslint-config-prettier": "^8.5.0",
    "eslint-import-resolver-meteor": "^0.4.0",
    "eslint-plugin-import": "^2.25.4",
    "eslint-plugin-meteor": "^7.3.0",
    "eslint-plugin-prettier": "^4.0.0",
    "eslint-plugin-vue": "^8.5.0",
    "mocha-sonarqube-reporter": "^1.0.2",
    "nyc": "^15.1.0",
    "prettier": "^2.6.1",
    "puppeteer": "^8.0.0",
    "selenium-webdriver": "^3.6.0",
    "standard-version": "^9.3.2"
  }

No one is using eslint with vue project and nested import ?

Thanks.

Hi,

For the reccord.

Instead of:

I put parser inside parserOptions and it works.

 
  "parserOptions": {
    "parser": "@babel/eslint-parser",
    "allowImportExportEverywhere": true
  },
1 Like