rule `default` should ignore `import` commonjs?

[JounQin]

https://github.com/un-ts/eslint-plugin-import-x/blob/v4.12.2/docs/rules/default.md#rule-details

import baz from './baz'

Otherwise, what's the replacement?

cc @SukkaW

[petercat-assistant]

The rule default in the eslint-plugin-import-x is designed to enforce certain import/export conventions. If you are using CommonJS modules and want to ignore the import statement for them, you might need to adjust your ESLint configuration or use a different approach to handle CommonJS imports.

In CommonJS, the equivalent of the ES6 import statement would typically be:

const baz = require('./baz');

If you want to continue using import statements while working with CommonJS modules, you might need to use a transpiler like Babel to convert ES6 modules to CommonJS, or configure your ESLint to allow such usage.

If you are looking for a specific configuration or workaround within eslint-plugin-import-x, please let me know, and I can help you further explore the documentation or configuration options.

[SukkaW]

https://github.com/un-ts/eslint-plugin-import-x/blob/v4.12.2/docs/rules/default.md#rule-details

IMHO, even if we are using import directive with the CJS module, to maintain the semantics we will still need to use import * as.

[JounQin]

@SukkaW eslint/eslint#19703

Sadly we can't.

import * as imported will add a new default property on imported, and the reference is different with import imported AFAIK.

In the rule description:

This rule currently does not interpret module.exports = ... as a default export, either, so such a situation will be reported in the importing module.

So I'd think it's a limitation of current implementation and we should resolve.

[ehoogeveen-medweb]

FWIW the default export of postcss started being recognized after unrs/unrs-resolver#115 and is now no longer recognized after the revert in unrs/unrs-resolver#131. It can also no longer find parse as a named export.

[JounQin]

@ehoogeveen-medweb

postcss should put import before require, that's how Node spec works: https://nodejs.org/api/packages.html#conditional-exports.

Just created a PR for you.

[ehoogeveen-medweb]

By my reading, that doesn't matter in this case because import only applies to import statements (and import() calls) and require only applies to require() calls; they're mutually exclusive. The key order only matters for the other conditions that can overlap.

Though you can require(esm) now and I believe using import cjs from 'cjs' has been possible since Node.js 13 - but if both variants are given in exports it still uses the one that's relevant to the import style of the importing module.

[JounQin]

No, we can only pass conditions into unrs-resolver, the order doesn't matter from ourside, that's postcss's package.json defines the source of truth. You can try import.meta.resolve('postcss') with node --conditions import --conditions require by yourself, just like JounQin/test#4.

import postcss from 'postcss' can also be compiled into const postcss = require('postcss'), so those codes are not the source of truth.

[ehoogeveen-medweb]

My package uses "type": "module" and import postcss, { parse as postcssParse } from 'postcss' works just fine at runtime with Node.js 22.16.0, without any compilation step.

[JounQin]

You can override the conditions setting on your need.

I'm not saying import postcss, { parse as postcssParse } from 'postcss' won't work, it works because there is no custom conditions passed, and our defaults allow both require and import.

And as I mentioned already:

This rule currently does not interpret module.exports = ... as a default export, either, so such a situation will be reported in the importing module.

And again, your own codes are not the source of truth, you can also compile you module into .cjs with a bundler if you want.

[ehoogeveen-medweb]

If your defaults allow both require and import, then why is the default rule complaining that there's no default export, and the named rule complaining that it can't find parse? These rules should base their context on the importing file as Node.js interprets it (as an ES module, in this case).

I don't understand what you're saying about my code not being the source of truth - surely Node.js itself is the source of truth here, and it works out of the box with the exports of postcss as currently defined. Alternatively, TypeScript could be a source of truth, but it too is fine with it (and errors if I, say, try to import pase instead of parse).

[JounQin]

As I said, that's postcss's package.json defining require before import, please read more carefully. I even made a PR for you.

These rules should base their context on the importing file as Node.js interprets it (as an ES module, in this case).

As I said several times, import is just the source code, the final compiled out can also be commonjs, for historic or whatever reason, we don't have such consensual to be Node.js context aware.

I don't understand what you're saying about my code not being the source of truth

Answered above.