[Autocomplete] Move useAutocomplete to the Unstyled package

[michaldudak]

One chunk of https://github.com/mui-org/material-ui/issues/27170

This change moves the useAutocomplete hook to the Unstyled package. The hook is reexported from the old location, so nothing should break.

I renamed the Value type in useAutocomplete.d.ts to AutocompleteValue, as this type is specific to the Autocomplete component. The type exported from Core has the old Value name to avoid breaking changes.

[mui-pr-bot]

Details of bundle changes (experimental)

@material-ui/lab: parsed: -0.00% 😍, gzip: +0.35%
@material-ui/unstyled: parsed: +30.13% , gzip: +30.51%

Generated by 🚫 dangerJS against 9c8e0ba

[oliviertassinari]

It seems that git is considering the moved filed as "new", not "moved". It sounds like we will lose the ability to blame. Could you double-check this aspect and look into keeping the history?

[michaldudak]

@oliviertassinari even though I moved the files from core to unstyled in one commit (which git correctly recognizes as a move) and created new ones in core in another, the whole diff between this branch and next does not show file movements.

[oliviertassinari]

the whole diff between this branch and next does not show file movements

The last time I faced this problem I have struggled to figure out who (git, github, github PR view, me) was doing it wrong or right. I recall Sebastian had it right in the past.

[eps1lon]

I recall Sebastian had it right in the past.

Contrary to popular believe git's internals have no notion of "moving" a file. Moving is only computed after the fact (e.g. git-diff, git-blame). You can configure what is considered a "move" in git-diff with find-renames.

git-mv is just a cross-platform convenience helper and basically equivalent to mv + git-add on unix.

So it seems like the default threshold is exceeded because we mix moving and changing in a PR. I would recommend we do one commit where we move and another where we change things i.e. two different PRs.

[michaldudak]

I would recommend we do one commit where we move and another where we change things i.e. two different PRs.

For git these will be just two commits, so it'll essentially be the same as currently on this branch - even though I made one commit with movement and the other one with editing, when diffing between the latter and the base, git does not recognize the movement (and it's not just a matter of GitHub's PR interface - commandline git shows the same result).

[eps1lon]

For git these will be just two commits, so it'll essentially be the same as currently on this branch

That's what I said, yes. This PR is just one commit.

Splitting this PR would work as the commit that just moved the files will actually mark the files as moved in the diff: 99fd646 (#27485)

[michaldudak]

I modified this PR to include just moving useAutocomplete to the Unstyled package (+ changes necessary for the green CI). Reexporting from Core is done in #27524.

Once this PR is merged in, I'll rebase #27524 on next and merge it in ASAP.

[eps1lon]

Looks good. GitHub blame should be able to pick up the move.

[oliviertassinari]

Ohh, thanks for the explanation Sebastian, it makes a lot of sense.

[oliviertassinari]

I'm merging to make the review on part two easier #27524