Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(sort-collections): avoid sorting exports by default #918

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 1 addition & 2 deletions docs/rules/sort-collections.md
Original file line number Diff line number Diff line change
Expand Up @@ -103,8 +103,7 @@ Defaults:
"dependencies",
"peerDependencies",
"overrides",
"config",
"exports"
"config"
]
```

Expand Down
1 change: 0 additions & 1 deletion src/rules/sort-collections.ts
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,6 @@ const defaultCollections = [
"peerDependencies",
"overrides",
"config",
"exports",
];

type Options = string[];
Expand Down
15 changes: 15 additions & 0 deletions src/tests/rules/sort-collections.test.ts
Original file line number Diff line number Diff line change
Expand Up @@ -132,7 +132,8 @@
}
}
}`,
options: [["exports"]],
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Testing] Oh, sorry, I wasn't clear in what I meant to ask for - could you please add a valid test too?

I think there are really two points of logic that are relevant+important to test for this change:

  • By default, the rule does not enforce sorting for "exports"
  • If added to the list in options, "exports" does get sorted

This test checks the latter but not the former.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JoshuaKGoldberg about this - should we consider warning developers or requiring a separate flag to enable dangerous keys? I think there is an opportunity here to educate people on the dangers of sorting exports and imports alphabetically (while still giving them the choice if this is what they want to do).

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe as a quick mention in the docs file that links to the first-party package.json docs? I don't think a separate flag is justified yet. Someone who reads through the docs to know about the option is probably pretty high intent anyway.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hahaha that is fair
I'm laughing because I'm realizing I have a cynical tendency to think people will not read the documentation lol

No worries, I will add a note in the docs 👍🏽

Copy link
Author

@GeorgeTaveras1231 GeorgeTaveras1231 Mar 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JoshuaKGoldberg I think this is my last alignment question.

I was working on the docs and realized that this rule only does a top-level sort (not recursively) so at the moment, it only causes problems if you have a condition object at the top level.

i.e.

This breaks when auto-fixed

{
  "exports": {
    "types": "./f.d.ts",
    "import": "./f.js",
    "default": "./f.cjs"
  }
}

This is ok

{
  "exports": {
    ".": {
      "types": "./f.d.ts",
      "import": "./f.js",
      "default": "./f.cjs"
    }
  }
}

Since the error case is easily distinguishable, it made me think we are putting too much responsibility on the consumer to know wether its safe or not safe to sort.
What do you think about just adding a check to the sorter? - to only sort if its not a condition object (the heuristic per the standards is to check if the keys start with .)

It would be a totally different approach, we may be able to leave exports in the list of defaults but make it safer.

I'm ok with putting this in a separate PR and closing this one, or repurposing this one. What do you think?

errors: [

Check failure on line 136 in src/tests/rules/sort-collections.test.ts

View workflow job for this annotation

GitHub Actions / lint

Expected "errors" to come before "options"
{
data: { key: "exports" },
messageId: "notAlphabetized",
Expand Down Expand Up @@ -214,5 +215,19 @@
}
}`,
},
{
code: `{
"exports": {
".": {
"import": "./index.mjs",
"require": "./index.js",
"types": "./index.d.ts"
},
"./package.json": "./package.json",
}
}`,
options: [["exports"]],
filename: "package.json",

Check failure on line 230 in src/tests/rules/sort-collections.test.ts

View workflow job for this annotation

GitHub Actions / lint

Expected "filename" to come before "options"
},
],
});
Loading