fix(import_resolver): fall back to element source URI when no library re-exports it#74
Open
pcj wants to merge 1 commit into
Open
fix(import_resolver): fall back to element source URI when no library re-exports it#74pcj wants to merge 1 commit into
pcj wants to merge 1 commit into
Conversation
… re-exports it ImportResolver.resolve returned null when no library in libs re-exports the element, even though the element's own source URI is always a valid Dart import. This stranded callers like dependency_config_factory with no way to produce a working import for the element. Under standard build_runner, libs is the full transitive package graph and the original loop almost always matched, so the null path was rarely hit. Under Bazel's rules_dart codegen action, libs is each package's src/ libraries only (not the public re-exporting library), so the loop fails to match for types like StackedService and codegen emits broken imports. Falling back to the element's source URI is harmless under build_runner (unreachable) and unblocks Bazel + any other host with a similar library scope.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ImportResolver.resolve returned null when no library in libs re-exports the element, even though the element's own source URI is always a valid Dart import. This stranded callers like dependency_config_factory with no way to produce a working import for the element.
Under standard build_runner, libs is the full transitive package graph and the original loop almost always matched, so the null path was rarely hit. Under Bazel's rules_dart codegen action, libs is each package's src/ libraries only (not the public re-exporting library), so the loop fails to match for types like StackedService and codegen emits broken imports.
Falling back to the element's source URI is harmless under build_runner (unreachable) and unblocks Bazel + any other host with a similar library scope.