-
-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
astro check
reports that a used function is not used
#476
Comments
Thank you for reporting this issue! This effectively a bug. This happens because of the shape of the generated TSX output, since the frontmatter is technically at the top level, the Moving this to the language-tools repo since this is ultimately a language-server issue (which also affects the editor, though in different ways) |
Hi, any plans to fix it in near future? Right now the only workaround is to suppress error by using I'm willing to submit a PR but I would need some hints where to start. |
This is unfortunately a huge amount of work. We need to change the shape of the TSX output, which implies changing mappings, which tends to imply changing some manual mappings in completions / code actions as well. If you're interested in tackling this, I can give further information, but it's a fair amount of work, in multiple programming languages and with also a fair amount of background needed 😅 |
Ok, so for now I will leave it, I will start with something minor 😅 |
A non-technical alternative would be to create a proposal for this to be changed to a throw, instead of a return. You could create a proposal here for this: https://github.com/withastro/roadmap/discussions Even it does look weird to throw things like that, it's actually a common pattern when wanting to top-level react to things and would be more valid JavaScript. |
Would this be easier to solve if we had script tags instead of frontmatter? |
Nope, same problem. From the editor tooling perspective, it being a script tag or a frontmatter doesn't really change much |
I see. Apart from throwing or exposing some sort of if (!slug || !username) {
Astro.response = noSuchRecipe();
return
} |
Or perhaps that's the root problem? Couldn't this be transparently fixed by astro by wrapping the frontmatter in a function (e.g. an Immediately Invoked Function Expression)? |
Yes and no, for two reasons:
It's honestly a problem that's way more complicated than it seems |
Okay, not sure I understood that 100% as I'm not familiar with the .astro compiler... (I was thinking of a hack to work on the string before it even is parsed into any AST... basically splitting the front-matter string after the imports, then wrapping the second part in a IIFE) But anyway, if it's not doable, then I vote for |
Just chiming in to say I've also encountered this, and it is very odd. In my case, I was able to suppress the TS error in the IDE (in VSCode at least) by re-assigning the import: import someResponse from "../someFile"
const fancyResponse = someResponse
...
return fancyResponse() It's more than a little clunky, but keeps the editor happy. However, I've not spent a huge amount of time with Astro, but so far I'm liking it - this is the first real ickiness I've encountered ❤️ |
Known astro-lang issue => withastro/language-tools#476
* core: update node, pnpm and green/yellow deps * core: update all core deps * format: run prettier Also fix prettier by adding the astro plugin * fix: eslint config * lint: fix all and format * refact: remove deprecated zod validations * refact: add console.logs to avoid false warnings Known astro-lang issue => withastro/language-tools#476 * fix: image service Also install now needed `sharp` for images * core: update pnpm-lock file
This is happening to me with astro check:
With other 13 hints more. |
@OrlandoBricenoB I believe in your case |
If you're open to a simple (hacky) heuristic that might be less work to implement, we could add a compiler step that takes any Though that wouldn't solve the error from still showing up in my editor intermittently. Weird that it doesn't do that consistently 🤔 |
I see there is already a proposal for this: withastro/roadmap#830 |
Same problem here. I had to remove |
I'm using this workaround until there's a fix. It's a little bit of extra code but allows me to keep I create a function that I can pass the function that export function avoidAstroTypeCheckBug(_: unknown) {
// See https://github.com/withastro/language-tools/issues/476 for more context.
return;
}
// In a .astro file
import { avoidAstroTypeCheckBug } from './avoidAstroTypeCheckBug';
import { createNotFoundResponse } from './createNotFoundResponse';
if (!someValue) {
avoidAstroTypeCheckBug(createNotFoundResponse);
return createNotFoundResponse();
} |
I had someting very similar to OP: function noSuchRecipe(): Response {
return new Response("<p>No such recipe</p>", {
status: 404,
statusText: "No such recipe",
headers: {'content-type': 'text/html'},
});
}
// Grab this recipe.
const { username, slug } = Astro.params;
if (!slug || !username) {
return noSuchRecipe();
} My workaround for now was to rename |
You could just do: createNotFoundResponse;
return createNotFoundResponse(); I guess yours is more explanatory |
I'm working on a fix here withastro/compiler#1028 |
@Princesseuh Amazing! I guess that means |
No, I'm only working on making it so top-level returns don't trigger an error in editor tooling + astro check, no changes to Astro itself. |
Includes bumping astrojs/check which resolves withastro/language-tools#476
🎉 thanks @Princesseuh! |
Re-opening this as I'm about to revert the fix. It did work for most cases, but some cases broke it horribly and led to confusing errors. Currently trying to work on a fix, but it is quite tricky. Apologies for the inconvenience! |
Thanks for the hard work @Princesseuh Going back to my workaround #476 (comment) |
Good idea! Works for me too. -const { userId, redirectToSignIn } = Astro.locals.auth()
+const { userId, redirectToSignIn: _redirectToSignIn } = Astro.locals.auth()
if (!userId) {
- return redirectToSignIn()
+ return _redirectToSignIn()
} |
What version of
astro
are you using?1.9.2
Are you using an SSR adapter? If so, which one?
Node
What package manager are you using?
pnpm
What operating system are you using?
Linux
Describe the Bug
Running
astro check
on:Returns:
but running the file actually shows the "No such recipe" output.
Link to Minimal Reproducible Example
https://stackblitz.com/edit/github-urvrsi?file=src/pages/index.astro
Participation
The text was updated successfully, but these errors were encountered: