microsoft / microsoft/TypeScript

new `Move to file` refactoring should avoid name collisions

Open
#54,130 0 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Experience Enhancement Suggestion
Dominant language
Go
Stars
111k
Forks
14.4k
Avg merge
1d 19h
Merged PRs (30d)
117

Description

Suggestion

I tested it in insiders + nightly in the following way:

export const getData = () => ({
  foo: true
})
const data = getData()
// target file
const getData = () => ({
  bar: false
})

const data = getData()

After moving

Actual:

const getData = () => ({
    bar: false
})

const data = getData()
export const getData = () => ({
    foo: true
})

Expected:

const getData = () => ({
    bar: false
})

const data = getData()
export const getData2 = () => ({
    foo: true
})
// original file:
import { getData2 as getData } from "./file2"

const data = getData()

I can even see the test that explicitly captures this case (added by @navya9singh in https://github.com/microsoft/TypeScript/pull/53542):
https://github.com/microsoft/TypeScript/blob/ea6441d3d77963b1c692c8aca023a822e039dc67/tests/cases/fourslash/moveToFile_unresolvedImport.ts that would obviously break real world code after. I would expect a to be named as a2 after moving I guess?

THe real problem is that sometimes you just can't tell wether specific file has confliciting top-level identifiers and you have to rename these symbols either in source or target file, but user also could rename these symbols after the refactoring instead (e.g. getData2 to something else). Introduce variable / function just use one function call to avoid name collisions:

https://github.com/microsoft/TypeScript/blob/7c378dbab3ab590835c3adbd260f37c97fba1111/src/services/refactors/extractSymbol.ts#LL1042C33-L1042C39

The same thing also applies for names coming from imports:

// source file
import { groupBy } from 'lodash'

groupBy([], (val) => val)
// target file
import { groupBy } from 'lodash'

groupBy([], (val) => val)

After refactor:

// actual
import { groupBy } from 'lodash'
import { groupBy } from 'rambda'

groupBy([], (val) => val)
groupBy((val) => val, [])
// expected
import { groupBy } from 'lodash'
import { groupBy as groupBy2 } from 'rambda'

groupBy([], (val) => val)
groupBy2((val) => val, [])

This code is not broken :shrug :.

This is painful when you have huge project that in process of migration from lodash to rambda api.

🔍 Search Terms

✅ Viability Checklist

📃 Motivating Example

💻 Use Cases

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with tests/cases/fourslash/moveToFile_unresolvedImport.ts and the move-to-file refactor implementation; the issue also points to src/services/refactors/extractSymbol.ts for existing collision-avoidance behavior. Reproduce the local-variable and import-name examples, then add coverage showing that moved declarations and imports receive unique names without breaking references.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.