Hi guys,
Sorry for polluting the issues, but I think that my question is something that others are likely to search for here too.
After the recent release of node 7.6 with async/await supported even without --harmony, I decided to drop babel from my node app, but keep linting rules from airbnb-base. Because bare node still does not support import * from syntax, I wanted to inherit the esling config, but introduce a rule that would report occurrences of import/export as errors, while keeping require & module.exports acceptable. Sadly, after two hours I'm still when I have started, i.e. both import and require are considered acceptable by eslint.
Could anyone suggest what one should put in their eslintConfig in addition to extends: "eslint-config-airbnb-base" to achieve a proper alignment with what node 7 can do on its own?
One important thing to change that I have discovered by now is this:
parserOptions: {
ecmaFeatures: {
experimentalObjectRestSpread: false,
},
},
Cheers!
I believe I solved the issue. The key was sourceType: 'script':
// index.js
module.exports = {
extends: ['eslint-config-airbnb-base'].map(require.resolve),
parserOptions: {
sourceType: 'script',
ecmaFeatures: {
experimentalObjectRestSpread: false,
},
},
env: {
node: true,
},
rules: {
'comma-dangle': [
'error',
{
arrays: 'always-multiline',
objects: 'always-multiline',
imports: 'always-multiline',
exports: 'always-multiline',
functions: 'never',
},
],
'strict': 'off',
},
};
yup, that's exactly the way.
However, I'd still recommend using babel, even for node-only.
@ljharb why? What's the benefit? Really curious, cuz I felt like I no longer need babel in the new projects after learning what 7.5 and 7.6 can do. The only two things missing bits now are import and {...rest}. Not ideal, but on the other hand there is no more need for downloading extra 100500 modules, configuring babel, managing source maps and building for production. Am I missing something?
Unless you never want to use new language features prior to their introduction in node, there will always be new features coming down the pike. Object rest/spread, class properties, private fields, decorators, the bind operator - are some interesting syntactic features that come to mind.
Reintroducing the babel step later is more work than just keeping it around now, even if you disabled every transform (altho you'd want trailing function commas and object rest/spread at least).
Most helpful comment
Unless you never want to use new language features prior to their introduction in node, there will always be new features coming down the pike. Object rest/spread, class properties, private fields, decorators, the bind operator - are some interesting syntactic features that come to mind.
Reintroducing the babel step later is more work than just keeping it around now, even if you disabled every transform (altho you'd want trailing function commas and object rest/spread at least).