"Move class to file" ask to export new file from source

[FMorschel]

If you have the following project:

In main.dart:

class A {}

class C extends A {}

In other.dart:

import 'main.dart';

void f(C c) {}

And you use "Move class to file" on C, the current output for other.dart is (#56658 for the unused_import):

import 'main.dart';
import 'c.dart';

void f(C c) {}

I'm not sure how this could be done, but I'd like to ask for a way for me to say if I want to add export 'c.dart'; inside main.dart so that other files don't need to change.

---

// CC: @DanTup

[dart-github-bot]

Summary: The "Move class to file" refactoring currently adds an unnecessary import statement to files that already import the original file containing the moved class. The user requests a way to specify whether to add an export statement to the original file instead, to avoid unnecessary changes in other files.

[FMorschel]

A little update, both of the following issues could also benefit from some form of "checking" before/after the assist. Imagine someone wants to add an import with both show and an alias/prefix. That might make the current list of options a little too big and noisy, so if we had some form of "check user" here, that might be interesting.

• Add quick fix for "Import package:x show y" #32234
• Import library with prefix assist #55863

Also, as noted on (#56265) there could be some form of "hiding" some options in the list project-wise or user-wise. That could also help with this specific problem of filling up the options list.

[FMorschel]

One more case: #56885

We could also ask (when making a new part file with this same feature - whenever it supports it) if we'd like to use the source file imports or add new imports on the specific file.

[bwilkerson]

... I'd like to ask for a way for me to say if I want to add export 'c.dart'; inside main.dart so that other files don't need to change.

That's a reasonable request.

I'm not sure what the UI would look like for that, but the easiest solution might be to introduce a "Move Top Level to File and export" refactoring.

Alternatively, we could ask users to do something like

1. Write an export directive for the new file.
2. Use the 'Create file' assist to create the file.
3. Use "Move Top Level to File" to move the declaration.

(That assumes that move-top-level checks to see whether the target file is already exported and leaves the imports in other files unchanged in the case, which I'm fairly certain it currently doesn't do but should.)