withastro / language-tools

Language tools for Astro
MIT License
270 stars 54 forks source link

Import aliases don't work with typescript in .astro files in vscode. #642

Closed miklschmidt closed 1 year ago

miklschmidt commented 1 year ago

Astro info

Astro version            v2.10.14
Package manager          yarn
Platform                 linux
Architecture             x64
Adapter                  Couldn't determine.
Integrations             None or couldn't determine.

What browser are you using?

Not relevant

Describe the Bug

When running yarn create astro selecting a strict typescript project with sample files, then following the guide to enable import aliases, import alias don't work in .astro files.

tsconfig.json:

{
  "extends": "astro/tsconfigs/strict",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@components/*": ["src/components/*"],
      "@layouts/*": ["src/layouts/*"]
    }
  }
}

src/pages/index.astro

import Card from '@components/Card.astro';

Doesn't work in VSCode. It compiles fine, but there's no types since ts can't find the definition. Aliases also seem to work fine from .ts/.tsx files.

What's the expected result?

import Card from '@components/Card.astro'; should result in a typed Card import.

Link to Minimal Reproducible Example

Minimal reproducible example is described above. Requires VSCode.

Participation

bnonn commented 1 year ago

I am having the same problem. The import alias works fine, yet Astro for VSCode underlines it in red and gives an error like this:

Cannot find module '@components/Cta.astro' or its corresponding type declarations. ts(2307)

This happens for most aliases and some other Astro imports, yet not others. It seems quite random. E.g.:

image image

My compilerOptions in tsconfig.json include:

    "baseUrl": "./src",
    "paths": {
      "@assets/*": [
        "assets/*"
      ],
      "@components/*": [
        "components/*"
      ],
      "@data/*": [
        "data/*"
      ],
      "@layouts/*": [
        "layouts/*"
      ],
      "@styles/*": [
        "styles/*"
      ],
      "@utils/*": [
        "utils/*"
      ]
    },

I tried adding a types.d.ts in my src/ folder, as follows (suggested by the support AI on Discord), but this made no difference:

declare module '@assets/*'
declare module '@components/*'
declare module '@data/*'
declare module '@layouts/*'
declare module '@styles/*'
declare module '@utils/*'

This is not breaking anything; it's just really annoying because what's the point of having linting like this if it's giving you false errors.

Princesseuh commented 1 year ago

Following the steps you described, everything works for me:

image

So, I'm not too sure what the issue is.

    "baseUrl": "./src",
    "paths": {
      "@assets/*": [
        "assets/*"
      ],
      "@components/*": [
        "components/*"
      ],
      "@data/*": [
        "data/*"
      ],
      "@layouts/*": [
        "layouts/*"
      ],
      "@styles/*": [
        "styles/*"
      ],
      "@utils/*": [
        "utils/*"
      ]
    },

Same thing with this config, everything works for me:

image
bnonn commented 1 year ago

Thanks. It seems unlikely this is affecting everyone as surely there would have been bug reports before. That said, it has been affecting me for...as long as I remember. This is just the most recent in a series of intermittent efforts to fix it.

Princesseuh commented 1 year ago

Thanks. It seems unlikely this is affecting everyone as surely there would have been bug reports before. That said, it has been affecting me for...as long as I remember. This is just the most recent in a series of intermittent efforts to fix it.

We also are using the same framework as Vue's language-tools, so if it was a widespread issue it would be affecting a lot of people 😅

I'll ask around if people have seen this before, sorry for the inconvenience

miklschmidt commented 1 year ago

I've had this issue for months. I've reproduced it via the above on 2 different physical machines Ubuntu 20.04, and WSL2 on Windows 11. I'm now reproducing it on the third machine, and just ran into this: image

If i switch to 14.18.3, i later get this: image

Didn't get this yesterday, but that makes it hard to reproduce currently.

I have the issue in my existing app on this machine though (same thing, several months, it started around Astro v2 i think).

Princesseuh commented 1 year ago

create-astro does not depend on create-strapi-app, not sure where that comes from, might be something else you have installed? Perhaps you installed that package globally once and yarn tries to install it again on every install, no idea.

How are you opening your workspace? Is your Astro project your only folder in your workspace or is it perhaps a big workspaces with many projects? It shouldn't matter, and no matter how I open the workspace everything works for me, but you know, gathering info

Princesseuh commented 1 year ago

Here's a video of me going through the process you described, let me know if you do anything differently / if I misunderstood something. As you can see in the video, everything is working for me.

https://github.com/withastro/language-tools/assets/3019731/dd529516-7f4c-49e3-ad0b-37788b3f0c22

bnonn commented 1 year ago

OK, so...

I had this in my tsconfig.json:

  "include": [
    "src/types.d.ts",
  ],

This is what the support AI in Astro's Discord channel suggested adding, along with the actual types.d.ts in src/. I removed this line, and the types.d.ts file, and now aliases are resolving correctly with no errors.

However, I only added this line yesterday. Before that, if I recall, I had a value of * in there, and then had some excludes set (node_modules etc). This in turn was a remnant of trying to fix the problem using StackExchange some weeks ago.

Seems like having that include directive is the problem, at least for me. I wonder if something like this is happening with @miklschmidt?

But here's what's even weirder:

Before I fixed this, I also opened the (then-broken) project in Webstorm. And it resolved those aliases just fine using the same (apparently broken) tsconfig.json. Wth?

miklschmidt commented 1 year ago

@Princesseuh

create-astro does not depend on create-strapi-app, not sure where that comes from, might be something else you have installed? Perhaps you installed that package globally once and yarn tries to install it again on every install, no idea.

That was exactly it, thanks. Reproducing on Ubuntu 22.04 now.

How are you opening your workspace? Is your Astro project your only folder in your workspace or is it perhaps a big workspaces with many projects? It shouldn't matter, and no matter how I open the workspace everything works for me, but you know, gathering info

I run code . from the root of the project. Ie, the astro root. The project folder is the only folder in my workspace.

@bnonn

Seems like having that include directive is the problem, at least for me. I wonder if something like this is happening with @miklschmidt?

Unfortunately that makes no difference on my machines, include isn't in my example's tsconfig.json either.

miklschmidt commented 1 year ago

Found the problem!

I had typescript@4.7.2 something installed globally, i removed that and now it resolves correctly, which doesn't really make any sense to me. VSCode showed 4.9.5 both before and after, which is distributed with vscode.. Switching to the workspace version 4.8.3, works as well. I'm not sure what's going on. I will try again on my other machines tomorrow.

Clearly something's fishy on my end, on all my machines... for some reason.

Princesseuh commented 1 year ago

Glad you figured it out, weird issue!

Since Astro 3.0 drops support for TypeScript 4 completely, I'll close this issue, as everything should be working on any TypeScript 5.x version.

If this is still affecting some of you, feel free to create a new issue with new details.

Farnsi commented 1 year ago

In my case this solve the problem:

tsconfig.json

{
  "extends": "astro/tsconfigs/strict",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@components/*": ["src/components/*"],
      "@layouts/*": ["src/layouts/*"],
    }
  },
  "include": [
    "src/**/*.d.ts",
    "src/**/*.ts",
    "src/**/*.astro"
  ]
}
stav commented 10 months ago

I had to add *.astro to my includes, now it works, thanks @Farnsi .

{
  "extends": "astro/tsconfigs/strict",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  },
  "include": [
    "src/**/*.d.ts",
    "src/**/*.ts",
    "src/**/*.astro"
  ]
}
FairyPenguin commented 9 months ago

01/23/2024

If anyone is checking this in 2024, Yes the issue is still there.

With Astro v4.1.2 | 5.3.2TypeScript Version

The only viable working solution is to include this in your tsconfig.json

"include": ["src/**/*.d.ts", "src/**/*.ts", "src/**/*.astro"]

Which I think needs to be added to the docs.

Note: You need to restart the dev server to say changes takes effect (In my case that was necessary)

Thanks to @stav @Farnsi for sharing this

Princesseuh commented 9 months ago

It makes a lot of sense to me that Astro files needs to be included in your TypeScript project for TypeScript things to work in Astro files.. I don't really see why you specify include in the first place, the default value already includes everything you would need and exclude can be used instead.

I could add a warning to the language server, though.

FairyPenguin commented 9 months ago

It makes a lot of sense to me that Astro files needs to be included in your TypeScript project for TypeScript things to work in Astro files.. I don't really see why you specify include in the first place, the default value already includes everything you would need and exclude can be used instead.

I could add a warning to the language server, though.

Maybe because this is not in the Astro docs for the typescript or the aliases guide.

https://docs.astro.build/en/guides/typescript/

And maybe not everyone is experienced with the configuration of ts and in this case, his first approach will be to check the Docs which didn't provide this info.

And Second, No it does not "makes a lot of sense" to include this in your typescript config when using ts in a project with ts. I use ts with react and next and this is added by default so you don't go down the config rabbit hole or at least it's clear in the "Docs" which is both very logical and normal.

To answer your question: I specified include because if I don't I get an error and the alias didn't work that's why.

I think you are missing the point or it's not clear, maybe I didn't clarify that well.

So I will describe the problem:

When I follow Astro Docs to use the Aliases I get the error and it doesn't work. Why? I don't know

the error: it can't find the module - even if everything is done correctly and like the docs.

Once I add include it works.

here is the full tsconfig.json file if this could help you

{
  "extends": "astro/tsconfigs/base",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@components/*": ["src/components/*"],
      "@icons/*": ["src/icons/*"],
      "@layouts/*": ["src/layouts/*"],
      "@types/*": ["/types/*"]
    },

    "jsx": "react-jsx",
    "jsxImportSource": "react"
  },
  "include": ["src/**/*.d.ts", "src/**/*.ts", "src/**/*.astro"]
}

So to make it simple, Without the include the Aliases are not working whatever solutions I tried were not working.

here is the base.json file

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "compilerOptions": {
    // Enable top-level await, and other modern ESM features.
    "target": "ESNext",
    "module": "ESNext",
    // Enable module resolution without file extensions on relative paths, for things like npm package imports.
    "moduleResolution": "Bundler",
    // Allow importing TypeScript files using their native extension (.ts(x)).
    "allowImportingTsExtensions": true,
    // Enable JSON imports.
    "resolveJsonModule": true,
    // Enforce the usage of type-only imports when needed, which helps avoiding bundling issues.
    "verbatimModuleSyntax": true,
    // Ensure that each file can be transpiled without relying on other imports.
    // This is redundant with the previous option, however it ensures that it's on even if someone disable `verbatimModuleSyntax`
    "isolatedModules": true,
    // Astro directly run TypeScript code, no transpilation needed.
    "noEmit": true,
    // Report an error when importing a file using a casing different from another import of the same file.
    "forceConsistentCasingInFileNames": true,
    // Properly support importing CJS modules in ESM
    "esModuleInterop": true,
    // Skip typechecking libraries and .d.ts files
    "skipLibCheck": true,
    // Allow JavaScript files to be imported
    "allowJs": true
  }
}

And as the two comments above me described without the include the Aliases are not working at all.

Princesseuh commented 9 months ago

Are you saying that it doesn't work when you have no include property at all? The default value of include is **/**, which, unless there's a bug, ends up functionally equivalent to the line you added in this context, and seems to be working for the majority of Astro users, including myself.

If it doesn't work, I'd be happy to look at that issue (with a proper reproduction).

As for the docs, we unfortunately cannot possibly account for all the unrelated settings people can use in tsconfig.json, there are many many ways, other than just include, to wrongfully configure your project that will break things.

FairyPenguin commented 9 months ago

Are you saying that it doesn't work when you have no include property at all?

YES, Exactly.

And this is what the other 2 comments above mine were saying 😅😅. It only worked with them too when they added the include only.

The default value of include is /, which, unless there's a bug, ends up functionally equivalent to the line you added in this context, and seems to be working for the majority of Astro users, including myself.

I know it works for some users but it's not working for others which is a strange behavior and maybe saying that there is a conflict with something "me and the others having in common".

Of course, I understand the Docs part, but I thought it was just something missing because the aliases were not working without, Now I understand it looks like a bug somehow.

I don't know if this could be helpful here or not but I find many bugs on the fly while I work in Astro I will list them here, Correct me if I'm wrong please:

1- When I add "React framework" if I add the component in a deep nest level the .module.css file gets unrecognized by Astro/compiler and it's not working and the only solution is to move the file up levels or change it to normal.css not a css module file.

2- The Path intellisesne in Astro is having a big issue it's not working most of the time and I had to restart the dev server, I'm working with Nextjs and Vanilla React too so I can compare very clearly this only happens when I use Astro the path to a file is lost and I had to write it manually Or Restart the dev server, For all files and extension and especially newly created files.

For both the problems above and the aliases problem I tried many fresh Astro installs to be sure 100% before I say it's a bug or not.

If it doesn't work, I'd be happy to look at that issue (with a proper reproduction).

I can upload the code to a repo and send you the link privately if this can help.

kirbby commented 9 months ago

I also had to remove excludes and references, in addition to adding the *.astro to the includes. I haven't updated any packages for 10 months, before this. image

kee-oth commented 9 months ago

I also needed to add the include property to my tsconfig.json file to get this working.

For reference, here is my working tsconfig.json file:

{
  "exclude": ["node_modules"],
  "include": [
    "src/**/*.d.ts",
    "src/**/*.ts",
    "src/**/*.astro"
  ],
  "extends": "astro/tsconfigs/strictest",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "#assets/*": ["src/assets/*"],
      "#auth/*": ["src/auth/*"],
      "#components/*": ["src/components/*"],
      "#database/*": ["db/*"],
      "#layouts/*": ["src/layouts/*"]
    }
  }
}
Princesseuh commented 9 months ago

A repo I could take a look at would be useful! I cannot reproduce this myself.

FairyPenguin commented 9 months ago

A repo I could take a look at would be useful! I cannot reproduce this myself.

Your Email?

FairyPenguin commented 9 months ago

@Princesseuh waiting for your GitHub email and username so i can share the private repo with you

Princesseuh commented 9 months ago

@Princesseuh waiting for your GitHub email and username so i can share the private repo with you

I don't really have a public GitHub email, isn't the GitHub username sufficient?

FairyPenguin commented 9 months ago

I found a solution i created a copied version of the project and extracted any sensitive info.

https://github.com/FairyPenguin/astro-reproduce

A repo with the same project and files.

@Princesseuh

firxworx commented 8 months ago

I had this happen just now in an Astro project where import aliases were previously working in *.astro files. My tsconfig and its include array was in-line with the other commenters who have it working.

TL;DR if your tsconfig agrees with the others and you still have this issue, check which version of TypeScript is being used by VSCode

Cause

For whatever reason VSCode decided to use its own version of TypeScript instead of the project version, despite the project including a .vscode/settings.json file with the line: "typescript.tsdk": "node_modules/typescript/lib". I have no idea why it would randomly switch to its version.

Fix

If you make a change, reload VSCode for it to take full effect and for it to reprocess all open tabs (including any *.astro files you may have open). I've found the most reliable way for a change like this to take effect is to fully exit and then reopen VSCode.

At least for me, the issue was resolved... once again...

frontendkris commented 8 months ago

I fixed all TS errors related to .astro files by upgrading typescript in my project to the latest version (4.4 to 5.4). Check out if you also have it outdated. :)

Chudroy commented 5 months ago

still getting this problem

mrcaidev commented 4 months ago

My problem was fixed by simply adding a baseUrl option in tsconfig.json.

Instead of doing this:

{
  "paths": { "@/*": ["./src/*"] }
}

Do this:

{
  "baseUrl": "src",
  "paths": { "@/*": ["*"] }
}
tresorama commented 4 months ago

Same problem here, but only with .astro files. With .ts all works as it should.

Resolved by launching Vs Code Command Palette > Developer: Restart Extension host.

// tsconfig.json
{
  "extends": "astro/tsconfigs/strict",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}
badrbelkeziz commented 1 month ago

Same problem here, solved it by adding "*/.astro" in the include key of tsconfig.json

include : ["**/*.astro", OTHER FILES ]