importsNotUsedAsValues = error should apply to export statements
See original GitHub issueTypeScript Version: 3.9.2
Search Terms: importsNotUsedAsValues, error, export
Code
import { Interface } from "./module";
export { Interface } from "./module";
With a "importsNotUsedAsValues"
set to "error"
.
Expected behavior:
tsc
would error on the export statement.
Actual behavior:
tsc
does not error on the export statement, it only errors on the import statement. TypeScript, by default, would elide both statements in the compile and should error in the same way.
Playground Link: N/A
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:8 (6 by maintainers)
Top Results From Across the Web
eslint - Is there a way to automatically fix `import type` errors ...
After a little more searching, I found ESLint rule consistent-type-imports which basically ensure the same as "importsNotUsedAsValues": ...
Read more >Languages and frameworks: TypeScript - JetBrains Rider
Here you can view problem descriptions, apply quick-fixes, navigate to the fragments in the source code where errors occurred, as well as fix ......
Read more >TypeScript errors and how to fix them
error TS1036: Statements are not allowed in ambient contexts. ... as a value and must use 'import type' because 'importsNotUsedAsValues' is set to...
Read more >Content Types - ESBuild
If the Node interpretation is used, this code will print { default: 'foo' } . Their rationale is that CommonJS code uses dynamic...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
https://www.typescriptlang.org/tsconfig
Why? It conspicuously says “import” and not “export” right in the name of the option. If there are docs that gave you this idea, let me know and I’ll update them. But the TSConfig reference reads pretty clearly to me that it’s about imports.
Setting
--importsNotUsedAsValues
to anything other than the default allows you to be more explicit about your module dependency graph. In eitherpreserve
orerror
mode, you can count on the fact thatimport type
declarations will always be elided and normalimport
declarations will never be elided (though this guarantee does not extend to the names imported, only to the statement on the whole—i.e.,import { Interface } from './foo'
becomesimport './foo'
).preserve
is important because it allows users to maintain a predictable module order and side effects when an import otherwise would have been elided.error
is frankly not that useful in my opinion, but it forces you to explicitly annotate imports that would be elided under the defaultremove
mode. This means that when you have an error-free compilation, the emit should be exactly the same as it would be if you had not specified--importsNotUsedAsValues
and not usedimport type
at all. So by definition, it offers you literally nothing over the default in terms of emit behavior; it’s purely for people who want the human-readable signal of “this import will be elided” and “this import will not,” but are happy with the module graph they get underremove
.This is why I think the original suggestion here does make sense—because an
export ... from
does affect the module graph and could be used to trigger side effects in the same way that imports do. Notably, not only doesexport { PureType } from './module'
not get an error with--importsNotUsedAsValues=error
, but it also gets fully erased in the emit inerror
/preserve
—we should probably be keeping it asexport {} from './module'
if we’re treating it as an effective import.