Mm I can see some of the issues you'll be experiencing then. As you mentioned, Pub love is important, even if you don't explicitly plan to use pub for any dependencies etc. [Aside: I would highly recommend investigating if it would be worth it as there are many great packages already in place many even by the dart team themselves. Some of which even replaced functionality of previously core libraries including crypto, unittest, matchers, args and more].
My first suggestion is to create a package (or possibly several depending on the scope of the code). These will be considered your 'shared libraries'. Any libraries code which you can/will reuse in other projects should be compiled into at least one package. Just one utility package would suffice, look at quiver as an example[1]. Once you do this, you can have a test directory in the package (not in the lib/ folder) which provides the unittest coverage for the public methods/functions/classes in your librar(y|ies) of that package. Within the test directory, you can have one main test file and sub folders for the specific libraries contained within the package.
In the lib/ directory most/all of your .dart files will reside (with the exception of the test ones). Within the lib directory you can use whatever structure suites you fancy. Any 'entry points' will usually be in a file in lib/xxx.dart where xxx is the same as your package's name. A difference is quiver where it has many upperlevel entry points (eg quiver/io.dart, quiver/time.dart). those files will refer to the implementation files usually by a relative import. eg:
// quiver/lib/time.dart
part 'src/time/clock.dart';
part 'src/time/duration_unit_constants.dart';
(Alternatively you can import them, or import and show depending on how you want to structure your library).
In your package's test/ directory (again top-level not under the lib directory) you import your package's libraries the same as you would import you would from another package:
// sharedlibrary_test.dart
import 'packages:sharedlibrary/sharedlibrary.dart';
import 'packages:unittest/unittest.dart';
void main() {
// full tests/groups here
test(....);
}
Next within your applications (like try_tetris), you would include a path dependency[2] to your shared package in the pubspec.yaml file (note your sharedlibrary package will also require a pubspec.yaml file naming it, etc even if you don't have any dependencies). Then within your bin/ or web/ directories you would import it with a package declaration:
// web/try_tetris.dart
import 'package:sharedlibrary/sharedlibrary.dart';
void main() {
// whatever code here
}
The try_testris package would have whatever app specific files in lib/, except your web page entry point in the web/ folder. Any tests specific to to the try_testris package would go in the toplevel folder test/ and it can also import any package local libraries or sharedlibrary files with the same mechanism mentioned above.
While I realize since you've been working quite a bit without using the pub package manager that it would involve a lot of changes to the current layout of your application, I think ultimately it would pay off for not only these projects to be shared with others and distributed how you may wish, it would also help with getting the fundamentals in place for future projects you may have which may require much more work and external packages.
Finally if you wanted to share some or any of the projects/files with a little documentation as to how you have them organized and what's shared etc, I may be able to help you wish sending a pull request to best convert them to packages and allow for the dart type package organization.
Matt