import "package:xxxmypackageName/xxxx" is not convenient for current project package,
can you add / alias for current package like javascript、 typescript or webpack?
for example:
import "/a/b.dart"; //<==import "package:xxxmypackageName/a/b.dart";
You can use relative imports https://dart.dev/guides/libraries/create-library-packages#importing-library-files
thanks !,but not easy!
This shorthand is problematic because of two choices: Dart uses URIs as import targets, and package: URIs put the package name in the path.
The URI resolution process is defined in an RFC, it's not something we decide, and when we use that process, resolving /a/b.dart relative to a base URI of package:xxxmypackageName/xxxx.dart, it will resolve to package:/a/b.dart. That is not a valid package URI because a package URI's path cannot start with /.
Package URIs should have put the package name in the authority, so it would have been package://foo/foo.dart instead of package:foo/foo.dart. Then /bar.dart would automatically resolve to package://foo/bar.dart inside that package.
There are two ways to approach this:
import foo; -> import "package:foo/foo.dart";import foo:bar/baz; -> import "package:foo/bar/baz.dart";import dart:io; -> import "dart:io";.import ../foo.dart; -> import "../foo.dart"; // like nowimport /foo.dart; -> import "package:currentPackage/foo.dart"; // what you ask forpackage: URIs. They are not really hierarchical URIs because the first name is special, so we could treat package:foo/foo.dart as if it was package://foo/foo.dart wrt. relative resolution. This should be safe because currently any relative resolution which affects the first path segment will generate a package URI path starting with /, which is invalid.package URIs to not print their // and to assume they are there when parsing).I have proof-of-concept code changing the resolution as described above: https://dart-review.googlesource.com/117542.
Most helpful comment
This shorthand is problematic because of two choices: Dart uses URIs as import targets, and
package:URIs put the package name in the path.The URI resolution process is defined in an RFC, it's not something we decide, and when we use that process, resolving
/a/b.dartrelative to a base URI ofpackage:xxxmypackageName/xxxx.dart, it will resolve topackage:/a/b.dart. That is not a valid package URI because a package URI's path cannot start with/.Package URIs should have put the package name in the authority, so it would have been
package://foo/foo.dartinstead ofpackage:foo/foo.dart. Then/bar.dartwould automatically resolve topackage://foo/bar.dartinside that package.There are two ways to approach this:
import foo;->import "package:foo/foo.dart";import foo:bar/baz;->import "package:foo/bar/baz.dart";import dart:io;->import "dart:io";.import ../foo.dart;->import "../foo.dart";// like nowimport /foo.dart;->import "package:currentPackage/foo.dart";// what you ask forpackage:URIs. They are not really hierarchical URIs because the first name is special, so we could treatpackage:foo/foo.dartas if it waspackage://foo/foo.dartwrt. relative resolution. This should be safe because currently any relative resolution which affects the first path segment will generate apackageURI path starting with/, which is invalid.(Basically, we change
packageURIs to not print their//and to assume they are there when parsing).