🐛 BUG: Cannot import typescript types

[MarcusOtter]

What package manager are you using?

npm

What operating system are you using?

Windows

Describe the Bug

In an astro component, it is not possible to import an interface from a typescript file.

• It does not matter if .ts is included or not (import x from "./x.ts" vs import x from "./x")
• It does not matter if the export is default or not
• It does not work to import type ... (see Example 2)
• It works perfectly as long as it is not an interface (functions/objects work)

Example 1

index.astro:

---
import { ToolInfo } from "./ToolInfo";
---
<p>Hello!</p>

ToolInfo.ts:

export default interface ToolInfo {
    name: string;
}

Output:

Error: Could not find "/src/models/ToolInfo.js"
    at load (file:///C:/[redacted]/node_modules/astro/dist/runtime.js:217:16)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async Server.<anonymous> (file:///C:/[redacted]/node_modules/astro/dist/dev.js:21:20)

Example 2

Same files as above, except index.astro has:

import type { ToolInfo } from "./ToolInfo";

Output:

SyntaxError: [6:13]: Import source must be string
    at report (C:\[redacted]\node_modules\meriyah\dist\meriyah.umd.js:189:13)
    at parseModuleSpecifier (C:\[redacted]\node_modules\meriyah\dist\meriyah.umd.js:3402:11)
    at parseImportDeclaration (C:\[redacted]\node_modules\meriyah\dist\meriyah.umd.js:3378:20)
    at parseModuleItem (C:\[redacted]\node_modules\meriyah\dist\meriyah.umd.js:2647:28)
    at parseModuleItemList (C:\[redacted]\node_modules\meriyah\dist\meriyah.umd.js:2635:27)
    at parseSource (C:\[redacted]\node_modules\meriyah\dist\meriyah.umd.js:2579:18)
    at Object.parseModule (C:\[redacted]\node_modules\meriyah\dist\meriyah.umd.js:6586:14)
    at Object.transform (C:\[redacted]\node_modules\snowpack\lib\cjs\ssr-loader\transform.js:33:25)
    at initializeModule (C:\[redacted]\node_modules\snowpack\lib\cjs\ssr-loader\index.js:75:56)
    at C:\[redacted]\node_modules\snowpack\lib\cjs\ssr-loader\index.js:63:28
    at C:\[redacted]\node_modules\snowpack\lib\cjs\ssr-loader\index.js:12:38
    at initializeModule (C:\[redacted]\node_modules\snowpack\lib\cjs\ssr-loader\index.js:89:34)
    at async Object.importModule (C:\[redacted]\node_modules\snowpack\lib\cjs\ssr-loader\index.js:166:25)
    at async load (file:///C:/[redacted]/node_modules/astro/dist/runtime.js:76:17)
    at async Server.<anonymous> (file:///C:/[redacted]/node_modules/astro/dist/dev.js:21:20)

Weird workaround

(thanks to @JSHSJ for finding this)

If you add any other export in the ts file it will work. With the same .astro file from Example 1, this works as a temporary workaround in the ToolInfo.ts file:

export default interface ToolInfo {
    name: string;
}

// Workaround hack
export function nothing() { }

Steps to Reproduce

1. npm init astro using template Starter Kit (Generic)
2. Add the file info.ts under src/pages with the following content:

   export default interface Info {
       name: string;
   }

3. Add this line in index.astro:

   import Info from "./info"

4. See error

   Error: Could not find "/src/pages/info.js"
   at load (file:///C:/projects/web/test/node_modules/astro/dist/runtime.js:217:16)
   at async Server.<anonymous> (file:///C:/projects/web/test/node_modules/astro/dist/dev.js:21:20)

Link to Minimal Reproducible Example (Optional)

No response

[jasikpark]

I've had similar problems trying to import types from Astro as well

[jasikpark]

I would rather like to be able to write interfaces in Astro files and export them so that I can use those types in consuming components.

Making interface imports work w/ regular typescript files would be great!

[matthewp]

This is likely a compiler bug, will make sure this is fixed in the new compiler work.

[jasikpark]

The weird workaround suggested seems to just return undefined rather than a valid type :/

[natemoo-re]

Confirming that this is fixed in the astro@next preview! See working demo.

Will put this in our milestone to be closed when that release is stable.

[natemoo-re]

Following up on my previous comment, the team has decided to close out issues that have been confirmed as fixed by astro@0.21.0-next.0, astro@0.21.0-next.1, or astro@0.21.0-next.2. Our hope is that this will help the v0.21 milestone remain as actionable as possible.

To verify that this issue has been fixed, you may

• Open a new astro@next project on StackBlitz
• Locally upgrade to the astro@next preview

  npm i astro@next
  # If using Framework renderers...
  npm i @astrojs/renderer-name@next

If you think we made a mistake, please reopen this issue!

If you run into any other problems with astro@next, please open a new issue.