Show doc comments before type expansions in hover information

[mediremi]

Before	After

When generating hover information, we currently show in order:

1. main type
2. expanded types
3. docstrings

A frequent issue I run into is that my expanded types hover information is long enough that the hover preview box must be scrolled to view docstrings.

In this PR, I've changed the order we present this information to:

1. main type
2. docstrings
3. expanded types

[pkg-pr-new]

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript-lang/rescript@7774

@rescript/darwin-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-arm64@7774

@rescript/darwin-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-x64@7774

@rescript/linux-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-arm64@7774

@rescript/linux-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-x64@7774

@rescript/win32-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/win32-x64@7774

commit: 6a89573

[Copilot]

Pull Request Overview

This PR improves hover information display by reordering the presentation to show docstrings before type expansions, making documentation more visible when type expansions are lengthy.

• Reordered hover information to display docstrings immediately after the main type, before expanded types
• Modified the hoverWithExpandedTypes function to accept and integrate docstring parameters
• Updated test expectations to reflect the new hover information order

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
analysis/src/Hover.ml	Core implementation changes to reorder hover elements and integrate docstring display
tests/analysis_tests/tests/src/expected/Hover.res.txt	Updated test expectations for the new hover format
tests/analysis_tests/tests/src/expected/JsxV4.res.txt	Updated test expectations for JSX component hover format
CHANGELOG.md	Added changelog entry documenting the feature

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

[nitpick] The pattern Some [] suggests that an empty docstring list should be treated the same as no docstring. Consider using a helper function or guard clause to make this logic clearer, as the pattern matching combines two conceptually different cases.

Suggested change

	| Some [] | None -> Markdown.codeBlock typeString
	let is_empty_docstring = function
	| None | Some [] -> true
	| Some _ -> false
	in
	match docstring with
	| d when is_empty_docstring d -> Markdown.codeBlock typeString

[zth]

Great stuff!