Dart quick fix of moving generated function to another file should move in the "part 'file.g.dart' " as well

[github-worst-company]

This tracker is for issues related to:

• Dart analyzer and linter

Clicking on quick fix then move to file only moves the required imports but doesn't move part 'application_support_directory_provider.g.dart'

Of which the imports and part looks like after moving file (the image has part added manually):
Current behaviour:

import 'dart:io';
import 'package:riverpod_annotation/riverpod_annotation.dart';

Expected behaviour:

import 'dart:io';
import 'package:riverpod_annotation/riverpod_annotation.dart';
+part 'application_support_directory_provider.g.dart';

• Dart 3.4.0-99.1.beta (beta) (Thu Feb 1 13:40:17 2024 -0800) on "windows_x64"

[bwilkerson]

Is the original library (the one containing the declaration before it's moved) being imported by the newly created library (that is, is utils/application_support_directory_provider.dart the original library)? I'm guessing the answer is 'no' because otherwise you probably wouldn't have added the part directive by hand, but wanted to ask rather than make an assumption.

If not, then I think that adding an import for the original library is the real solution.

It's absolutely true that the newly created library needs to import the original library if the code being moved references something from the original library that isn't also being moved. The bug is probably that we're not considering declarations in the original library that come from part files when deciding whether to add an import of the original library.

But I think that moving the part file is probably the wrong solution. It would be good if we could recognize that the @riverpod annotation is used by a code generator so that we could add the part directive in the new file, but we don't currently have enough information to be able to do that. I suspect that the best workflow we can support for this kind of situation is:

1. Select the declaration to be moved and invoke the 'move to file' refactoring.
2. Run the code generator to create the new generated file and to update the old generated file (unless it's no longer needed).
3. Add the part directive for the new generated file.
4. Remove the import of the original library if it's no longer needed.
5. Remove the old generated file and it's associated part directive if the file is no longer needed.

I'd love to automate more of this process but I don't think we have enough information to be able to do so at this point.

Also, we should evaluate whether macros will solve this problem before putting too much effort into a solution.

[github-worst-company]

Apologies, I had a slight oversight. What happened is that the build runner wasn't running on watch, so moving the file did when work build runner is not running, at the expense that 2 files were left as is, the generated file and the original file which now only contains imports(presumably for the generated file) and the "part file.g.dart"

So basically if you move a generated function to a new file, the .g file will stay there, and the original file will also stay there and only contain imports and the part.

Here's a function in a standalone file called test_function.dart before moving.

import 'package:riverpod_annotation/riverpod_annotation.dart';
part 'test_function.g.dart';

@riverpod
String testFunction(TestFunctionRef ref) => 'A String';

The code when moving the function into a file called test_function_two.dart

// this file is test_function_two.dart
import 'package:riverpod_annotation/riverpod_annotation.dart';
import 'package:salam_app/utils/test_function.dart'; // 

// Function doesn't give error because it imports the generated file
@riverpod
String testFunction(TestFunctionRef ref) => 'A String';

Then only these lines are left in the original file of test_function.dart

import 'package:riverpod_annotation/riverpod_annotation.dart';
import 'package:the_app/test_function_two.dart'; // Not sure why it imports the file after moving the function

part 'test_function.g.dart';

However when build runner is running on watch

Then test_function.dartfile gets messed up as there's no annotation but there's part and it deletes the generated file, so function that was moved to test_function_two.dart doesn't work anymore unless we add the part.

[bwilkerson]

I agree that this is a bad experience, and I'd love to make it better. Unfortunately, our tools have no way of knowing the behavior of any given code generator, or even whether a code generator is being used to generate a file, so it isn't clear what we can do in this situation.