Export files are not updated when moving folders

[JFixby]

So basically when i move one folder to another inside project the export files stay the same and break imports.

[JFixby]

Similar to the #30294

[bwilkerson]

@jwren Can we get IntelliJ to ask server for (and apply) the edits that are needed to fix this kind of problem?

[JFixby]

I would suggest to make all public classes exported by default and deprecate the export files.

[bwilkerson]

An issue like this can either be addressed at the language level or can be addressed at the tooling level. The wording of these two issues made it sound like you were asking for an improvement to the tooling.

If you'd like to propose a language change then I would recommend creating a separate issue explaining what changes you'd like to see to the language. Describe the problem that your proposed change would solve, but phrase the request in terms of the change you're proposing, not the problem that's prompting the request. Be sure to also describe the disadvantages of such a change (such as the backward compatibility issue) and how the changed language would handle the namespace control issues that import and export directives currently solve (including subtleties, such as deferred loading and conditional imports). The more complete the proposal from a language design perspective the more likely it is to be given serious consideration.

[JFixby]

I know this is just bug in IDE-plugin and it will probably be fixed.

However the bug wouldn't exist at all if the Dart importing system had a proper design. I'm just referring to the issue mentioned before: #30299

Dart dependencies are managed by specifying a file path in a source file.
In Dart import says: Go find this project, inside there is this folder, and then there is another... at some point you'll find the source file, inside there is a class... What do you mean it's not there? Probably he moved and changed his identity, but who knows...

Actually class that uses import needs only the interface of the imported class. He can't care less about the source file location of the import and it's IDE-project name.

For example in Java import says: I need this class. He is known to the world under the name com.uitl.Stack and that's it.
The import source file location is hidden from class-user behind IDE or a runtime environment.

It is important to understand that dependency class source file location and dependency name are two different concepts. Treating them as the same like Dart does is obviously wrong and leads to problems.

Treating them as different concepts will actually handle backward compatibility, namespace control and other issues. For example you wouldn't need conditional imports at all.

Otherwise there is the whole set of future bugs and long discussions about fixing import-related problems like this one reported here.

[alexander-doroshko]

This seems to be tracked as https://youtrack.jetbrains.com/issue/WEB-18864.