Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Inconsistent behavior of "export as" symbols.

See original GitHub issue

TypeScript Version: 3.4.0-dev.20190305

Search Terms: export alias


This is file of some-lib:

export { LongNameOfInnerClass as PublicNameClass } from './long-name-of-inner-class';

This is other file, that import above lib:

import { PublicNameClass } from 'some-lib';

new PublicNameClass(); // Here hints is OK

new PublicNameClass(wrongArgument); // Error ref to LongNameOfInnerClass

Expected behavior: TypeScript hints have same “export as” aliases for working code and for errors.

Actual behavior: TypeScript hints for the working code are different from the hints for errors.

Related Issues: Not sure, but it seems that this issue has a similar problem: symbolToName does handle exports of namespaces

Issue Analytics

  • State:open
  • Created 5 years ago
  • Comments:6 (1 by maintainers)

github_iconTop GitHub Comments

Fabianopbcommented, Mar 11, 2019

Bingo! That shows the behavior as you described! I’d be interested in working on this issue, is that fine @RyanCavanaugh and @KostyaTretyak ?

Fabianopbcommented, Apr 5, 2019

I’ve started investigating the issue and that specific error is reported from src/compiler/checker.ts around line 19560 (file is too long to get a reference link), here:

if (right.escapedText && !checkAndReportErrorForExtendingInterface(node)) {
  reportNonexistentProperty(right, leftType.flags & TypeFlags.TypeParameter && (leftType as TypeParameter).isThisType ? apparentType : leftType);

Considering that this would be my first contribution in this repo, I’m trying to understand how it works, so I thought about two approaches:

  1. The leftType here has the original name and not the alias. So if there’s a way to do that, we could check if an export alias exists and show it instead of the original name.
  2. Wherever the node is defined, its name could already be defined as the alias, so when we get to that line of code up there, leftType will be already called by its alias.

Does this make sense? Any tips what is the best approach?

Read more comments on GitHub >

github_iconTop Results From Across the Web

AIX export symbols incorrect (#19163) - CMake - GitLab
Exporting too many symbols causes problems because a shared library may re-export symbols from another library causing confused dependencies, ...
Read more >
Lld-link does not export data symbols - Using Clang
I use the linker to create a DLL, specifying symbols to export on the command line like so: clang++ -fuse-ld=lld -shared -Wl,-export:myfunc ...
Read more >
exported and fixing import visibility - Discussion - Swift Forums
Exporting feels more like a build target level configuration to me for a couple of reasons. First, it's a global option for the...
Read more >
Dynamic Library Design Guidelines - Apple Developer
... Specifying the Scope and Binding Behavior of Exported Symbols ... But this is also an incompatible revision because the API changed.
Read more >
Inconsistent panel border width when exporting as SVG with ...
This might just be because of how devices handle clipping masks. If you want the more consistent behaviour, you can try turning of...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found