🦋 Changeset detected

Latest commit: e2e4556

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Thanks for the PR! The scope of this PR is pretty big. IMO, I would prefer if a discussion was opened first so that we could gather community feedback on the feature to see if there's enough demand for it, and to agree and align on scope.

I'm personally on the fence about how useful this would realistically be -- the value add feels negligible.

Implementation wise, it's a bit unusual to add a formatter option where it's mostly used in assists. We have a pretty high bar for adding formatter options. It would make a lot more sense (at least for now) to have the option be per-rule.

I'm personally on the fence about how useful this would realistically be -- the value add feels negligible.

I feel that value addition is particularly based on the nature of project. The moment I upgrade Biome, it was a clear that my team will not go along this kind of import sorting. And there is also a demand building up from the community #6122, and from that you can see different impact of selecting sorting logic. If you feel I can open open discussion in Github/Discord anywhere you want to gather more feedback.

Implementation wise, it's a bit unusual to add a formatter option where it's mostly used in assists.

Yes, I started PR earlier by setting up option per assist, but later observed that this is actually a formatter option like indent_style, attribute_position and bracket_spacing etc this seems more natural that sort_mode come under formatter. If you prefer otherwise, I can move those to per assist option.

Agreed a little more discussion might've helped, but it seems indeed #6122 makes a good case for why we want this functionality.

Also agreed that the setting should be an assist option rather than a formatter option though. The formatter itself doesn't apply sorting/ordering at all, and having the option there would give the impression that it does, which I think is a bit misleading. And who knows, maybe some people want different orderings for keys than they want for imports, for instance, so per assist makes it more flexible too. I think if you make that change indeed, we can accept this PR.

I am not sure to see the relation between sort_mode and #6122.
To me, #6122 suggests adding a way to customize the order of property names, allowing you to place name before author in files such as package.json.
There is no request to switch to alphabetical order instead of natural order.

The natural order provided by Biome is really close to an alphabetical order. The main difference is number sorting.
It could be nice to open a discussion and explain why it is an issue in your case.

Signaling support for this feature 🚀

@arendjr I had updated the PR with options specific to the assists rules. And kept schema configuration in a way that it not breaking any change in previous release.

Though having one last error now.

thread 'specs::source::use_sorted_keys::sorted_alphabetical_js' panicked at /biome/crates/biome_analyze/src/options.rs:23:9:
assertion `left == right` failed
  left: TypeId(0xa0d302f587c7b29fa87ec27d3ecb9043)
 right: TypeId(0xca5b249dab56609f7f688ff4e4b80f35)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- specs::source::use_sorted_keys::sorted_natural_js stdout ----

thread 'specs::source::use_sorted_keys::sorted_natural_js' panicked at /biome/crates/biome_analyze/src/options.rs:23:9:
assertion `left == right` failed
  left: TypeId(0xa0d302f587c7b29fa87ec27d3ecb9043)
 right: TypeId(0xca5b249dab56609f7f688ff4e4b80f35)


failures:
    specs::source::use_sorted_keys::sorted_alphabetical_js
    specs::source::use_sorted_keys::sorted_natural_js

test result: FAILED. 1472 passed; 2 failed; 0 ignored; 0 measured; 14 filtered out; finished in 3.36s

And this is because in configuration crate we are picking useSortedKeys attributes from JSON analyzer package. And with following change we have different Options structs for useSortedKeys in both JS and JSON analyzer package.

Please suggest how to fix it? Is there a crate which is usually used in such cases to have shared structs?

For shared options, no not yet. There's an open PR for it #5543

So I think for now you will have to duplicate the options. Would that work for you?

I don't think so. The problem comes from there being 2 rules, one for each language, so the name conflicts.

I don't think so. The problem comes from there being 2 rules, one for each language, so the name conflicts.

Yes two same name rules for two languages. One for json and other for js, but from configuration exported as json options.

The assert logic want it to be exact same reference of struct. So it works for json but not for js.

Good approach would be to assert if the options are same not the exact object reference.

Well, no, we do want it to be the same struct because we want to keep the options in sync, and that's the easiest way to do that.

Feel free to copy the approach in that PR I linked. I'm on mobile right now so I can't give you links, but IIRC that PR moves options into the common biome_analyze crate.

I tried to only have methods inside the compareable_token now in reference to the not put the sort_mode into every token, that was redundant and overwhelming for memory.

Please review now @dyc3 @arendjr

Related to the error for cross crate options for similar rules, it seems to have following options for us.

1. Add simple crate for it in this PR starting with options for useSortedKeys for JS and JSON, and then add more in next PRs for other options.
2. We already using JSON-Schema for options, so we may implement schema fingerprint hashing, and then compare those. As long options are same, the schema for options will be same and that will work in comparison.

Please review the code and suggest the next steps.

CodSpeed Performance Report

Merging #6506 will degrade performances by 61.19%

_{Comparing nazarhussain:nh/import-sort-config (e2e4556) with next (275cc8b)¹}

🎉 Hooray! codspeed-rust just leveled up to 3.0.3!

A heads-up, this is a breaking change and it might affect your current performance baseline a bit. But here's the exciting part - it's packed with new, cool features and promises improved result stability 🥳!
Curious about what's new? Visit our releases page to delve into all the awesome details about this new version.

Summary

⚡ 1 improvements
❌ 3 regressions
✅ 110 untouched benchmarks
🆕 1 new benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

It seems #5543 is almost ready to be merged. Is it okay we keep this on hold until it is ready? You'll probably need a rebase after that, but it should solve the issues with the codegen/schema.

@arendjr I had fixed the lint/fmt issues and also added the changeset. For the website update, is it possible to open a PR there now or have to wait for this one to be merged first? The instructions are not that much clear for understanding.

Wait, I may be leading you astray with the suggestion to open a PR against the website: Maybe the docs should simply be updated by adding docs to UseSortedAttributesOptions and similar structs in this PR. Once you do that, I'm not sure what remains to be updated on the website itself, but that's something @ematipico should be able to tell you.

Yeah, apologise for the lack of proper directions regarding this. I will make sure to address it in the coming days.

For docs, even if they are shared, we must document them in the rule/action itself.

When you document the option like this

struct UseSortedAttributesOptions {
   // i am documentation
	foo_bar: bool
}

The documentation will only appear as a description of the schema, so we should keep it generic and it's applicable to all rules that will consume that option.

However, we also want to update the docs of the rule/action too so we can create an example:

## Options

The action accepts the following options

### `nameOfTheOption`

This option is amazing and does this. In the following example, the options makes the code look differently beauftilf

```json,options
{
	"options" {
		"nameOfTheOption": true
	}
}
```

```js,use_options,expect_diagnostics
function fn() {}
```

Of course, the code block has to change to meet the expectations of the option. In this case, we need to use expect_diagnostics so users can see how the option affects the code.

@ematipico I added doc comments with updated options. Please review and suggest if there is nay change needed.

@ematipico Thanks for your feedback. There were no invalid/valid cases for the assists I believe so I added examples which shows what diagnostic after sorting.

Let me know if that's good or suggest any changes.

@nazarhussain the PR is still failing, can you please address it? It seems that the code blocks you added in the docs have syntax errors.

Seems issue happens from base branch, as lint passing for me locally.

cargo lint
....
....
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 25.51s

I will try to rebase or update the branch.

@nazarhussain the PR is still failing, can you please address it? It seems that the code blocks you added in the docs have syntax errors.

@ematipico Please rerun the CI and re-review this PR.