Language: can add "/" alias instead of package:xxxmypackageName

Created on 5 Sep 2019  ·  4Comments  ·  Source: dart-lang/language

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";

request

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.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:

  1. Make a different syntax for imports, preferably without quotes, which are then resolved to URIs in a slightly smarter way than just relative URI resolution. Say:

    • 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 now

    • import /foo.dart; -> import "package:currentPackage/foo.dart"; // what you ask for

  1. Change the relative resolution rules for package: 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.
    (Basically, we change package URIs to not print their // and to assume they are there when parsing).

All 4 comments

You can use relative imports https://dart.dev/guides/libraries/create-library-packages#importing-library-files

thanks !,but not easy!

  1. directive(/...) or path alias better than relative ,becuase in actually dev ,files moved or restructured frequency,the relative path will lost import or confuse the developer self.
  2. use the self project package name in import string is not easy for code share or copy.
    dart should do better just like javascript ,typescript or webpack coming from dev. for years

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:

  1. Make a different syntax for imports, preferably without quotes, which are then resolved to URIs in a slightly smarter way than just relative URI resolution. Say:

    • 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 now

    • import /foo.dart; -> import "package:currentPackage/foo.dart"; // what you ask for

  1. Change the relative resolution rules for package: 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.
    (Basically, we change 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.

Was this page helpful?
0 / 5 - 0 ratings