Xo: Compatibility with planned node.js native ESM import resolution

Created on 30 May 2019  路  8Comments  路  Source: xojs/xo

It appears that the node.js plan for native ESM is that file extensions will be mandatory. This directly conflicts with current xo rules import/extensions and unicorn/import-index. I'm opening this ticket to start the discussion about how/when xo should deal with this.

It appears that import/extensions only applies to import statements and not require. If/when proposal-pkg-exports sees progress import/extensions may need to be updated. unicorn/import-index applies to both import and require, might need an option so it can be applied to require only if that is desired. Might also need/want a rule that forbids direct import of the package main source.

In one of my private projects that is targeting ESM I have the following xo.rules in my package.json:

    "import/extensions": [
        "error",
        "always",
        {
            "ignorePackages": true
        }
    ],
    "unicorn/import-index": "off"

Personally I'm not a fan of this but I feel like the decision has already been made.

Most helpful comment

Ideally XO should automatically disable those rules on modules (i.e. type: "module" directories and .mjs files)

All 8 comments

I think we can just disable import/extensions in the next version. It's not that useful anyway. No one uses file extension in CommonJS. As for unicorn/import-index, we could add an option of whether to apply to import or not, PR welcome for that.

I know this would be a rule reversal but I think xo should report an error if ES module extensions are omitted, obvious exception for the bare package name as shown in my xo.rules above. My reason for this is that import something from './somefolder' is an error in the browser and native node.js ES modules. This does not effect CJS (import/extensions does not process CJS).

I've posted a bug to eslint-plugin-unicorn. If nobody else posts a PR for it I'll try taking a look when I get a chance (likely after I get nyc@15 released).

I had to disable these 3 rules to use --experimental-modules with AVA

      "import/extensions": 0,
      "import/no-useless-path-segments": 0,
      "unicorn/import-index": 0

https://github.com/fregante/webext-storage-cache/commit/47b0077fe94b4ee765582bb03276ccd3269dc3e9#diff-b9cfc7f2cdf78a7f4b91a753d10865a2

Ideally XO should automatically disable those rules on modules (i.e. type: "module" directories and .mjs files)

if it is some hybrid node/browser module you should definitely use extension and no index import. Using "never" is bad practice and should be removed IMO

require has always worked well and will continue to work well without extensions

{
    "import/extensions": "error",
    "import/no-useless-path-segments": "error",
    "unicorn/import-index": "error"
}

import initially inherited require鈥檚 behavior and is still often mapped to it, but going forward perhaps XO should enforce the opposite on ES Modules:

{
    "import/extensions": "off",
    "import/no-useless-path-segments": "off",
    "unicorn/import-index": "off"
}

ES modules being:

  • .mjs
  • type: "module"
  • import/export found in the file

This detection however might not be easy in XO鈥檚 context.

Detection will be too hard and not worth it. I'm just going to make this good by default.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pizzafox picture pizzafox  路  7Comments

sindresorhus picture sindresorhus  路  6Comments

dawsbot picture dawsbot  路  5Comments

tony-kerz picture tony-kerz  路  3Comments

lagden picture lagden  路  3Comments