Don't enforce module to precede import per se

[nvie]

The lint rule I contributed recently in #49 may have been a tad bit too strict. Some package authors prefer to use the module condition to override the require (or default) condition only, but not using it for import statements. That should be fine. The purpose of the bundler-specific module condition is to allow you to override/intercept require()s mostly, and instruct the bundler to include the ESM version instead.

As a package author, you can still also decide to place the module condition before the import and as such use it to also intercept import statements. Both approaches are fine, as a module and import definition will typically resolve to the same module in practice. So it's mostly an author preference, and not something we should enforce with a lint rule.

This PR loosens the check by only enforcing that module precedes require. It drops the requirement that it also precedes import.

An example of a project that got a false positive from the too-strict check is https://publint.dev/zustand. They use import, and only fall back to a module redirect for require() statements (via their default condition). That's perfectly fine.

---

For example, examples 1 and 2 are fine, but example 3 is not (the "module" will never be used):

Example 1:

{
  ".": {
    "module": "index.mjs",  // 👍 Still fine
    "import": "index.mjs",
    "require": "index.cjs",
  }
}

Example 2:

{
  ".": {
    "import": "index.mjs",
    "module": "index.mjs",  // 👍 Previously rejected, now also fine
    "require": "index.cjs",
  }
}

Example 3:

{
  ".": {
    "import": "index.mjs",
    "require": "index.cjs",
    "module": "index.mjs",  // ❌ Lint error, because this condition will never be used
  }
}

[bluwy]

Sounds fair to me. Trying to think if removing a message is considered a breaking change, but it's probably fine. Will cut this as a patch later.

Thanks again for keeping up with this!

[nvie]

Trying to think if removing a message is considered a breaking change, but it's probably fine.

I think it's fine too.

Will cut this as a patch later.

Thanks for the merge, and for this invaluable tool for package authors! 🙏