Error importing type definitions?

[kernel-io]

If you find you are getting an error while trying to import type definitions, make sure to add the name of the package with type definitions to the excludes array in your autoImport configuration in ember-cli-build.js 👍

[ef4]

Thanks for reporting and for suggesting a workaround. I think we can fix this so it does the right thing automatically.

Option 1: When we can't resolve a module, before giving up and generating an error we could try to resolve a type definition, and if we find one we would ignore the import (as it doesn't imply any runtime code is needed).

Option 2: If we switch to using a babel plugin for analysis (which has been discussed before), and if we can control the relative order of our plugin and the one ember-cli-typescript installs, we can do analysis after TS has already compiled away the type-only imports.

[kernel-io]

I'm not educated regarding the benefits of using the babel plugin for analysis, however if using it brings more benefits / opens up more avenues than option 1, wouldn't it be better to follow that path? Option 1 seems very very specific to this issue only?

[tschoartschi]

We actually hit the same problem... But we can not work around this issue because the package has typings and source in the same package. What we would need is:

autoImport: {
    exclude: ['web-sdk/lib/definitions']
}

import WebSdk from 'web-sdk'; // behind this real JS code sits
import {GlbViewer} from 'web-sdk/lib/definitions/glb-viewer-core/src/glb-viewer'; // this is only type information

export const GLB_CANVAS_ID = 'glb-canvas-container';

export default class GLBViewer extends Component {
    private _glbViewer: GlbViewer;

    constructor() {
    	this._glbViewer = await WebSdk.getGlbViewer();
    }
}    

Since the package web-sdk is a package we control we could adjust it, if it makes sense but many customers use it already so we need a good reason to change it. There where no problems with any of the other major frameworks (Vue, React, Angular, custom Rollup build).

Would be great if we could provide a workaround for Ember users

[tschoartschi]

@dfreeman showed us a workaround in discord:

export default class GLBViewer extends Component {
    private _glbViewer: import('web-sdk/lib/definitions/glb-viewer-core/src/glb-viewer').GlbViewer;
}

But that's not very nice, it looks awkward and furthermore the IDE always suggests the former import style. So we always have to manually adjust

But the good thing is, we are not blocked with this workaround anymore 😃

[ef4]

There is another case that I think is worth including in this issue. When importing something only for use as a type, you really don't want that to create a real runtime dependency on the module. That interferes with your ability to lazily load the module.

Moving our analysis into a babel plugin isn't even a slam dunk, because there would still be finicky timing concerns there. Changes to the implementations of other babel plugins could break the analysis.

So I'm starting to think we need to introduce our own detection of type-only imports.

[boris-petrov]

Is this bug going to be circumvented when using the soon-to-be-available import type functionality of TypeScript?

[ef4]

Yes, that should work, though I still think we should fix the other case too.

[boris-petrov]

@ef4 - just to let you know that the same problem exists even with type-only imports unfortunately. Is that something that is more easily fixable than the original issue? At least to have some way of doing this.

P.S. Well, the workaround from above still works, so it's not actually that big of a deal. But just to inform you that type-only imports from TypeScript 3.8 and Babel 7.9 have the same problem.

[mansona]

Has anyone tried this in Typescript 4.x or 5.x? I'm curious if the type-only import in newer Typescript might have fixed this 🤔