Designating when an import is a type/interface

[kengorab]

Just started out using typescript in a react app at work, and we've encountered situations like below:

import {AnalyticsContainer} from '../containers/analytics-container';
import {LocationTable} from '../components/table/location-table';
import {NormalizedTableData} from '../reducers/MonitoringReducer';
...

One of those imports (NormalizedTableData) is a type, and at a glance it's difficult to determine that. There's nothing that indicates that all 3 aren't types.

I'd like input on this suggestion, but what I propose would be a special (optional?) syntax to denote type imports, so that the above would read as follows:

import {AnalyticsContainer} from '../containers/analytics-container';
import {LocationTable} from '../components/table/location-table';
import type {NormalizedTableData} from '../reducers/MonitoringReducer';
...

This way, it's definitely clear which imports are types and which aren't. I think an example that was more confusing than the one above is this one:

import {connect, MapStateToProps} from 'react-redux';

where both a function export and a type are being imported (especially since the name MapStateToProps suggests it'd be a function and not a type). I think

import {connect, ...} from 'react-redux';
import type {MapStateToProps, ...} from 'react-redux';

makes it easier to distinguish between the two, and makes the code easier to read. Opinions/thoughts?

[kitsonk]

Why is it important to distinguish it? An import can be anything. Intellisense would inform you what that import actually is. What make the arbitrary distinction? What about Interfaces and Classes which are only imported for their type information?

[DanielRosenwasser]

The benefit here is actually avoiding issues related to import elision. A lot of people are surprised about TypeScript's behavior of scrapping an import if none of its imports are used as values. That has two benefits:

1. Users no longer run into this surprise.
2. Enables modules to be independently compiled without a type-checking & resolution phase - it becomes very explicit which types of imports need to be elided. My understanding is that this behavior is often expected for build tools like Webpack & Broccoli.

Of course the downside is that there's a lot of thought you're forcing users into over the types of things you're importing. It's also more to type.

[mhegazy]

For the record this has been discussed in #2812. also note that any changes here will be a breaking change, and will have to be done under a flag, --noImportElision or so.

#9191 already tracks this issue. so i would say this is a duplicate of #9191.

[RyanCavanaugh]

I really think we should move to a model where you have to opt in to module elision using syntax like this, starting with a mode like --noImplicitElide which tells you about imports which you don't use values from.

This also solves the "force import" problem by making all imports sticky unless explicitly unstuck.

[kitsonk]

I would think some sort of compiler flag would be 100% better than mangling the syntax.

[mhegazy]

I would think some sort of compiler flag would be 100% better than mangling the syntax.

I do not think you can do one without the other. there are modules that are type-only modules. currently the way to differentiate between these is to "infer from usage". if we add a flag to disallow this "inference", then we need to have a way for users to "declare" which is which. using import type ... from .. was the proposal discussed in #2812.

[jamiewinder]

I was just about to post about the same thing. There are a few occasions where I'd like to be explicit that 'I only want to import the types from this module', otherwise I risk accidentally having the module imported when it wasn't the intention. This can be easy to do in some circumstances (in particular using the type in a parameter = not import, vs. checking a type with instanceof = imported).

An import types type clause would make this clear and infractions would be highlighted.