Glob or RegExp import/export

[EhsanAramide]

Usage

In some situation, we need to export (sometimes import) multiple files, and the whole of them are located in the same directory

Syntax

we can import/export with glob or RegExp syntax. With this feature, we don't need to export like this or creating multiple mini-libraries:

library my_lib;

export 'src/core/buttons/text_button.dart';
export 'src/core/buttons/image_button.dart';
// and so on...

instead, we can use it like:

library my_lib;

export 'src/core/buttons/*_button.dart';

I'll happy with your ideas and comments =)

[lrhn]

This would probably have to be part of a larger reworking of the import statements.
Dart currently uses URIs as library designators, not just paths. URIs are well-defined, and * is a valid URI path character, so it wouldn't be right to just change behavior.

[EhsanAramide]

@lrhn Tnx about your comment, but, dart team has any plan or solution to make these situations easier?

[lrhn]

There is no current plan to add glob/regexp support.

We are, and have long been, considering making import syntax more convenient (#649), but it's not part of any current schedule.
If we get back to that idea, we may also want to consider glob patterns.

(I'm not sure I like glob patterns for imports. Currently you can click on an import in your editor and be sent to the imported file. A glob import won't be able to do that. It also risks accidental imports. Say, if your editor saves a temp file named _temp_.dart in a directory where you do an import foo/*.dart, you will start including that file as well. I'd probably lean more towards a way to make the editor expand such a shorthand into all the actual imports, so you won't have to type any more, but you're safe against accidental additions.)

[EhsanAramide]

Thank you about your response.🤝🙌

[michpolicht]

Say, if your editor saves a temp file named _temp_.dart in a directory where you do an import foo/*.dart

Sane editors don't use prefix, but rather suffix e.g.yourfile.dart.swp. Like colleague said - it's not about imports, it's about exports. We don't need to click imports to see imported files, it's useless...

[natebosch]

We should not add a feature where it becomes a potentially breaking change to add a new library to a package. Adding new features in new libraries is an approach that we occasionally use specifically to avoid major version bumps.

[michpolicht]

Could you elaborate? What breaking change are you talking about? What new features in what libraries?

[michpolicht]

Dart currently uses URIs as library designators, not just paths. URIs are well-defined, and * is a valid URI path character, so it wouldn't be right to just change behavior.

You confuse URIs with URLs all over the place... Example of URI urn:isbn:0-486-27557-4 . If you want to import stuff such as books into dart, then congrats....

[lrhn]

The breaking change would be someone importing package:foo/*, then the authors of the foo package adds a new library package:foo/foo_io.dart which only works if dart:io is available. The glob import happily imports that as well, unconditionally.

If glob patters only work for relative imports, it's probably less dangerous.

Also, URLs are URIs, and the Dart Uri class implements the syntax of https://datatracker.ietf.org/doc/html/rfc3986. That's also the class used to parse imports.

[michpolicht]

Programmers shall not be that dumb to not be aware that package:foo/* imports everything from foo. If we would start thinking this way and protect programmers from thinking about their actions, then rm * should be banned in the first place. Package author can add dart:io dependency to the existing foo dart imports, can't he? And for the second time I point out to you that this feature would be specifically useful for exports and not imports....

URLs are of course URIs, but you clearly need to support only its subset, that is URL.