Skip to content

Reference libraries with @docImports #56528

Open

Description

@goderbauer

Imagine we have a library as follows:

/// Long and extensive documentation about this library
library foo;

// Good stuff in this library.

I would now like to refer to that library comment from another file/package:

/// Bla bla bla.
///
/// The details are explained in the [foo] library.
void bar() {
  // ...
}

I would like to have [foo] link to the doc on the library foo;. Currently, this doesn't seem possible with docImports in a way that makes the comment_references lint happy.

Activity

  1. goderbauer commented on Aug 20, 2024

    @goderbauer
    ContributorAuthor
  2. dart-github-bot commented on Aug 20, 2024

    @dart-github-bot
    Collaborator

    Summary: The user wants to link to the documentation of a library using @docImports but the comment_references lint prevents this. They propose using [foo] to link to the library's documentation, but this functionality is currently unavailable.

  3. added
    area-languageDart language related items (some items might be better tracked at github.com/dart-lang/language).
    triage-automationSee https://github.com/dart-lang/ecosystem/tree/main/pkgs/sdk_triage_bot.
    type-enhancementA request for a change that isn't a bug
    on Aug 20, 2024
  4. added
    devexp-serverIssues related to some aspect of the analysis server
    P2A bug or feature request we're likely to work on
    and removed
    area-languageDart language related items (some items might be better tracked at github.com/dart-lang/language).
    on Aug 20, 2024
  5. srawlins commented on Aug 20, 2024

    @srawlins
    Member

    It's a bit unique because the name of the library (a la library foo;) is not anything that can be used or even referenced by code (as opposed to, say, an import prefix name). So there is no element, for example, that is provided by an import, or a shared namespace from one or more import prefixes, that represents the library. The named library is also becoming less popular, and I don't think it's a good idea to implement a feature that requires a name on a library directive.

    I think the strategy we're likely going to go with is to allow you to reference a library as its import prefix. So that you could refer to foo with:

    /// @docImport 'foo.dart' as foo;
    library;
    
    // OR:
    import 'foo.dart' as foo;
    
    /// Hello [foo].
    var x = 0;

    One shortcoming of this strategy is that import prefixes are not generally tied to a single import; they act as a shared namespace. I think it's not a huge shortcoming, as we can just report an "ambiguous element" warning if you try to reference [foo] and foo is a shared import or doc-import prefix. It might require an awkward or sub-optimal implementation, tying a prefix to the (singular) URI of the library that it's tied to. I'm open to other ideas.

  6. removed
    triage-automationSee https://github.com/dart-lang/ecosystem/tree/main/pkgs/sdk_triage_bot.
    on Aug 22, 2024
  7. added
    area-devexpFor issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages.
    and removed on Feb 21, 2025
  8. added a commit that references this issue on Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2A bug or feature request we're likely to work onarea-devexpFor issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages.devexp-serverIssues related to some aspect of the analysis servertype-enhancementA request for a change that isn't a bug

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions