importsNotUsedAsValues: preserve is not preserving

[robpalme]

Bug Report

My interpretation of the "importsNotUsedAsValues": preserve option is that the goal is to emit value imports as-is. So that you can rely on the JS emit reflecting the JS you write. Here is a case that seems to violate that.

🔎 Search Terms

importsNotUsedAsValues preserve import binding missing skipped omitted import for side-effects JS+types

🕗 Version & Regression Information

• This is the behavior in every version I tried

⏯ Playground Link

Playground link with relevant code

💻 Code

// @importsNotUsedAsValues: preserve

// @filename: child.ts
export default 1

// @filename: main.ts
import d from './child'
eval("d");

🙁 Actual behavior

JS emit for main.ts is missing the import binding.

import './child';
eval("d");

🙂 Expected behavior

The value import should be preserved.

import d from './child';
eval("d");

[andrewbranch]

Hmm, it was an intentional decision that --importsNotUsedAsValues=preserve wouldn’t change the behavior of eliding the actual imported names; it would just keep the module dependency graph as you wrote it. Are there any use cases for this besides stringified execution?

[robpalme]

Ok, I think that's fair.

I was hoping this feature would achieve preservation of the original JS code, i.e. avoiding dead identifier elimination. But I see it does not have that ambition so this is not a bug and I will close it. And having written all this up, I'm now thinking that was an unreasonable assumption on my part 😉

As background, this issue was detected because we ban the import "thing" form (to discourage relying on side-effects) in a build rule that operates after TS->JS conversion - and that was erroring despite the source code not using that form - but I view that as an "us" issue and not convincing general argument. I was also trying to test some name-shadowing behavior by disabling the type-checker but was thwarted - again this is not a practical use-case.

Answering your question, I think stringified execution is the only practical case. In this case, it seems there is no way to get TypeScript to emit the legitimate input JS code even if you disable the checker. So instead, when you detect in your tests or runtime execution that the code is faulty, the workaround is to add a redundant usage site to prevent the compiler from eliminating it.

IMO this is a super-mild case of breaking the JS+Types model because we can't passthrough plain JS. It's an unavoidable transform. Maybe it's also a category mismatch because TypeScript is kinda doing the work of a minifier. Other simplistic forms of dead code, such as unused var declarations, are not eliminated. I appreciate that eliminating type names from the import statements is essential core functionality, and that "not statically detectable as a used value" is a neat heuristic/approximation for achieving that. Fixing that whilst preserving isolated 1:1 per-file transpilation seems to require more thought. I think this is worth thinking about for the future but it's not an urgent matter.

[andrewbranch]

So this same thing came up in the context of Svelte’s transpilation process—they had to write a custom transformer to re-add back imports that were removed because they look unused, but were in fact used in template code, which TS doesn’t understand. Moving some conversation from #43687 and continuing it here.

In #43687 I proposed a mode where:

1. import type declarations are removed (as they are now)
2. import (without type) declarations are not touched whatsoever, regardless of usage—that is, imported names are not removed.
3. It is an error to import anything that is only a type without using import type. (Contrast to --importsNotUsedAsValues=error, which allows pure types to be imported without import type as long as the same import declaration also imports at least one value.)

because

1. That transformer could be removed.
2. You would no longer need to be careful about combining type and value imports, because it would be enforced that you don’t do it.

That seems much better than the status quo, because it would improve transpilation performance and guard against a pitfall that seems very easy to fall into.