Skip to content
This repository has been archived by the owner on Jan 14, 2025. It is now read-only.

Recognize URIs starting with dart-macro+. #148

Closed
wants to merge 1 commit into from
Closed

Recognize URIs starting with dart-macro+. #148

wants to merge 1 commit into from

Conversation

lrhn
Copy link
Member

@lrhn lrhn commented Feb 7, 2024

Recognize URIs starting with dart-macro+
Such URIs belong to the same package as the the rest of the URI would, but are not package: URIs, and do not have a corresponding package: URI.
In this way, they behave like files inside the package, but outside of lib/, even if they are dart-macro+package: URIs.

Such URIs belong to the same package as the
the rest of the URI would, but are not `package:` URIs,
and do not have a corresponding `package:` URI.
In this way, they behave like files inside the package,
but outside of `lib/`, even if they are `dart-macro+package:`
URIs.
@lrhn
Copy link
Member Author

lrhn commented Feb 7, 2024

Not actually sure I want to land this. This package shouldn't need to know anything about dart-macro+ prefixes, because its one job is to understand package_config.json files.

@jakemac53
Copy link
Contributor

Not actually sure I want to land this. This package shouldn't need to know anything about dart-macro+ prefixes, because its one job is to understand package_config.json files.

Yes I agree, I do wonder if we should be updating the spec though. Conceptually, macro generated augmentations are a part of the same package as the library they are augmenting, and we should expect people to encounter these URIs.

This would make it harder to change the scheme prefix strategy though in the future, and I know not everybody is happy with it (we just needed to move forward and unblock folks).

@lrhn
Copy link
Member Author

lrhn commented Feb 9, 2024

The big question is which tools can end up with a dart-macro+uri, and whether we can expect those tools to know how to deal with it (meaning remove the prefix before calling pkgcfg.packageOf(uri)).

The same tools need to remove the prefix before calling uri.resolve(importUri) to resolve an import. The Uri class treats package: URIs specially, but not dart-macro+package: URIs, so the result may not be the same if resolving without first removing the prefix.

We might want to provide a macro_uris package that those tools can use for any operation where it might matter whether a URI is a macro-URI. Then they can do macro_uris.resolve(baseUri, relativeUriString) instead of baseUri.resolve(relativeUriString), and similarly for macro_uris.packageOf(packageConfig, uri).

Not nice, but at least puts all the functionality into one place, then it's just a matter of using that everywhere.

@mosuem
Copy link
Member

mosuem commented Dec 11, 2024

Closing as the dart-lang/package_config repository is merged into the dart-lang/tools monorepo. Please re-open this PR there!

@mosuem mosuem closed this Dec 11, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants