Skip to content

Add refactoring to use default import #19659

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
2 commits merged into from
Nov 3, 2017
Merged

Add refactoring to use default import #19659

2 commits merged into from
Nov 3, 2017

Conversation

ghost
Copy link

@ghost ghost commented Nov 1, 2017

Fixes #19261
Currently this will only activate if --allowSyntheticDefaultImports is enabled.

@ghost ghost force-pushed the useDefaultImport branch from 44919e8 to 6d49aeb Compare November 1, 2017 18:42
@ghost ghost requested a review from amcasey November 1, 2017 19:24

const useDefaultImport: Refactor = {
name: actionName,
description: actionName,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be localizable, e.g. getLocaleSpecificMessage(Diagnostics.Convert_to_default_import),
name should be not be modified, it should act as an identifier

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the locale is changed after boot this will have the wrong description, since this object is created immediately. This would affect other refactors too. Should we fix this?

function getAvailableActions(context: RefactorContext): ApplicableRefactorInfo[] | undefined {
const { file, startPosition, program } = context;

if (!program.getCompilerOptions().allowSyntheticDefaultImports) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@weswigham we will need to add your new commandline argument to enable the interop behavior here as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you go look at the PR, I have a similar but more precise quickfix which triggers on a diagnostic added when a namespace object is misused.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need both. The quick fix for the error, the refactoring for style change even without an error.

Copy link
Contributor

@mhegazy mhegazy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need another one for .js files to convert require to either import d from "mod" or import * from "mod" based on the shape of the module

@ghost ghost merged commit d54ad4b into master Nov 3, 2017
@ghost ghost deleted the useDefaultImport branch November 3, 2017 15:31
@ghost
Copy link
Author

ghost commented Nov 3, 2017

@mhegazy Could you clarify what you mean by "based on the shape of the module"? When should we use a namespace import instead of a default import?

@mhegazy
Copy link
Contributor

mhegazy commented Nov 3, 2017

Logged #19719 to track that

@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants