TypeScript: Rename a symbol of a named export: Do not create export alias

unckeck the following preferences in settings to make it work:

typescript.preferences.useAliasesForRenames

I’ll second this: a global option for the old behaviour feels necessary. This new alias does not work at all with the way some people work and imposing this new “feature” on people for something as common as symbol rename is not nice.

I’m sorry but for me the “improved” version is actually felt like a bug that is now preventing me from using renaming all together: I don’t want my codebase to be littered with aliases.

Just let us rename stuff please. Even a rollback of the feature altogether would be better, with an option to opt-in for alias renaming when things are properly figured out.

Does the setting typescript.preferences.useAliasesForRenames in vscode solve the problem?

This behaviour is terrible.

Honestly, this new export alias behavior is cumbersome for refactorings. If you have something like export {Y} and you rename it to Y2, the result is

export {Y as Y2}

In order to get all symbols in the module to be also named Y2, I have to manually delete Y in the export and then fix all Y lines in the module. I also have to pay attention, that I rename the symbol Y in the export statement itself (not somewhere else in the module). Otherwise, there is just an alias created in the export and the rest of the workspace that imports Y does not get the new name.

Before, I could just grab any reference of Y symbol, press F2 and it gets renamed in all places (module+workspace).

All in all, I also would really appreciate to have the old behavior back

While we didn’t explicitly mention exports, symbolically they behave very similarly to destructuring and I don’t see why we wouldn’t have made them behave the same way.

However, I can understand wanting a rename mode that works the old way, too - so i’ll make this as a suggestion.

It would be great if we can have both renaming behaviors at the same time, rather than disabling some behavior once for all.

9 times out of 10 I would prefer it to work like the old way.

For example, using destructuring (not imports):

const initialState = {
  hello: 'there'
}

export class App extends Component<Props, typeof initialState> {
  state = initialState

  async componentDidMount() {
    const { hello } = this.state;
  }
}

When I Rename Symbol on hello in the function I want it to rename hello in initialState too. And vice versa.

I usually do not get naming right the first time around. Often I’ll just go w/ x to not get hung up on naming until I get something working, and maybe rename things a few times before I’m done. The old behavior of rename symbol was great for this.

I’m 😢this behavior was changed without providing an option to maintain the old behavior.

It’s 2020 now, any further progress?

I tried to refactor a prop from a parent React Component with a child SFC, and got the following (crazy) behaviour:

Before rename

// Parent Component
<ChildComponent
    hasError={this.state.disabled}
/>

// Child Component
interface ChildProps {
    hasError: boolean;
}
ChildComponent: React.SFC<ChildProps> =({
    hasError,
}) => (<div>{hasError}</div>);

After rename

// Parent Component
<ChildComponent
    disabled={this.state.disabled}
/>

// Child Component
interface ChildProps {
    disabled: boolean;
}
ChildComponent: React.SFC<ChildProps> =({
    hasError: disabled,
}) => (<div>{hasError}</div>);

It correctly renamed the interface, then aliased the props for actual usage in the ChildComponent(!) This cannot be the desired behaviour…

Isn’t there a fix yet?

Apparently for someone, somewhere, this is how it is supposed to work!