Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

typealiasing an external type breaks for imports with a local name #2397

Closed
matt2e opened this issue Aug 16, 2024 · 0 comments · Fixed by #2401
Closed

typealiasing an external type breaks for imports with a local name #2397

matt2e opened this issue Aug 16, 2024 · 0 comments · Fixed by #2401
Assignees

Comments

@matt2e
Copy link
Collaborator

matt2e commented Aug 16, 2024

Steps to reproduce:

  • Import an external package but give it a local name
  • Create an FTL type alias that uses a type from this external package

Expected result:

  • type alias of the widened external type works correctly

Actual result:

unsupported external type "[PATH]"; see FTL docs on using external types: tbd54566975.github.io/ftl/docs/reference/externaltypes/
            [PATH]: unsupported type "[VAR NAME]"

Some digging shows that the problem starts around here: https://github.com/TBD54566975/ftl/blob/main/go-runtime/schema/typealias/analyzer.go#L54

@github-actions github-actions bot added the triage Issue needs triaging label Aug 16, 2024
@ftl-robot ftl-robot mentioned this issue Aug 16, 2024
@matt2e matt2e self-assigned this Aug 16, 2024
@github-actions github-actions bot removed the triage Issue needs triaging label Aug 16, 2024
github-merge-queue bot pushed a commit that referenced this issue Aug 19, 2024
fixes #2397

`pass.Pkg.Imports()` did not always* include the local name alias from
the import statement, so instead we need to do our checks via `PkgName`
which does include it.

*it includes it in the example in our tests, but didn't in the case that
our partner project was hitting...
I've added another test case that previously failed like theirs did.
safeer pushed a commit that referenced this issue Aug 19, 2024
fixes #2397

`pass.Pkg.Imports()` did not always* include the local name alias from
the import statement, so instead we need to do our checks via `PkgName`
which does include it.

*it includes it in the example in our tests, but didn't in the case that
our partner project was hitting...
I've added another test case that previously failed like theirs did.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant