Better code refactoring with regards to relative import paths

[MarvinHannott]

When you decide to split a library into multiple files and move them into a new sub-directory to better structure your code, you face the problem of relative import paths; you have to edit every single import regarding the moved library.
It would be convenient if there were a solution for this like Rust's mod files.

[Levi-Lesches]

By following pub conventions, you can save a lot of work. Consider this structure:

project
 └── lib
     ├── main.dart
     ├── data.dart
     └── src
         └── data/
             ├── data1.dart
             └── data2.dart

data1.dart and data2.dart each have your data classes in them, and data.dart looks like this:

export "src/data/data1.dart";
export "src/data/data2.dart";

Then your main.dart can look like this:

import "package:project/data.dart";  // includes data1 and data2

void main() {
  // use the dataclasses
}

Now, if you want to move all your data files into project/lib/src/data/specific_folder/, all you have to do is edit the exports in data.dart. The rest of your project is okay, as long as it imports package:project/data.dart.

[MarvinHannott]

But that only works for public stuff. Well, I guess it isn't too bad when we just mark it as "private" or "internal", though that's quite ugly. On the other hand, Rust's solution for sub-modules is quite sophisticated and makes sure that every module is self-contained, meaning we don't have to edit files at multiple locations, risking leaking private data.

[Levi-Lesches]

But that only works for public stuff. Well, I guess it isn't too bad when we just mark it as "private" or "internal", though that's quite ugly.

I use this format for my own personal projects -- I'm not sure what you mean here, it works fine. If you mean within the src folder, you can import package:project/data.dart even from data1.dart.

[MarvinHannott]

I'm not sure what you mean here, it works fine.

Yes, it works, but this way you export all internal data structures and functions that the user shouldn't know about. Also, it contradicts the advice of the Guide

When importing a library file from your own package, use a relative path when both files are inside of lib, or when both files are outside of lib. Use package: when the imported file is in lib and the importer is outside.

And it's just not very neat to have to maintain a file outside the 'sub-package'. It feels a bit like maintaining a header file, and in most C/C++ projects, there is one directory which contains all the header files, which gets messy.

At the same time, I am not trying to make a bigger issue out of it than it actually is.

[Levi-Lesches]

Yes, it works, but this way you export all internal data structures and functions that the user shouldn't know about.

It feels a bit like maintaining a header file

True, but this way you get to control what you export. I don't export everything in my sub-libraries for that exact reason, so having a file that you control may mean extra work, but it gives more control, if you want it.

Also, it contradicts the advice of the Guide

Oh, I use relative imports within sub-libraries, I agree with you.