-
-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Could not find a declaration file for module 'accessible-astro-components' #40
Comments
Hey @Hugo-Persson! Thanks for submitting the issue 😄 I think you forgot to paste in the error? This library is currently build using vanilla JavaScript. I do not have the necessary knowledge (yet) to transform it to TypeScript. |
The error is likely This gives Prop type safety and autocomplete but doesn't check children right now for things like Breadcrumbs and Accordian. I'd have to check with the Astro crew to see if that's possible as I couldn't get it to restrict return types. I'm not 100% sure on on all the types yet. There are a few props that have default parameters that I have left as optional that might be better off required. I'd be happy to submit a pull request here if you'd like to add it to this repo or rework it to submit to definitelyTyped. |
Hey @david-abell, thanks for elaborating on this issue and taking the time to create an example. I'll have to take your advice on this one, seeing as I don't have much experience with TypeScript 🤔 Would reworking it to Also, thanks for suggesting to do a pull request on the matter, I appreciate all the help I can get 😊 Ever since launching v2 of the Accessible Astro Starter I've been very short on free time. Let me know and then I'll assign the issue to you 😄 |
Happy to help Mark, these are great little components to work with. While I'm no typescript master myself, I would personally recommend adding the types to the repo rather than I've done a quick test with a local repo and its just a matter of having the types as an It is also possible to move component Prop type declarations into the Frontmatter of the components themselves since they are I'll want to check with the Astro team before pulling the trigger on either of these methods since I can't find a code example but moving props to the components would look like this: //add interface Props to Card.astro frontmatter
interface Props {
url?: string;
img?: string;
title?: string;
footer: string;
}
const {
url = '#',
img = 'https://fakeimg.pl/640x360',
title = 'Default title',
footer = 'Your name'
} = Astro.props
// index.d.ts
type CardComponent = typeof import("./Card.astro").default;
export const Card: CardComponent;
// instead of:
// no changes to Card.astro
// index.d.ts
interface CardProps {
url?: string;
img?: string;
title?: string;
footer: string;
}
export function Card(_props: CardProps): unknown; Let me know if you have a preference. |
Hey @david-abell, first off, thanks for your extensive research and examples on the topic! You've made a clear understanding of what is possible 😊 Secondly, thank you for your patience! I know I'm not that quick to reply, all due to being short on free time lately, so I appreciate your help. As for the options your suggesting, adding Let me know what you think! |
Hey @markteekman happy to help. I'm not currently employed so I've got nothing but free time right now 😄. I should have a pull request ready somewhat soon. I'm finishing up some basic jsDoc parameter descriptions first since otherwise the way Astro processes components seems to hide any useful descriptions. I've had to add I don't think its worth updating the component scripts in these components to typescript unless you want to start learning the language . The component scripts aren't exposed or type checked by Astro so no typing errors in them will be exposed to the users. They'll just work regardless of whether the project is TS or JS. It would also add dependencies to the project since Typescript would be required. |
Hey @markteekman Sorry to ping you again immediately, I was just going over diffs and realized the Original
After formatting...
|
Hey @david-abell! Thanks for putting in the time, even if you've got nothing but free time right now 😉 Adding prettier is a good idea though! And to be honest, the formatting of the pagination component seems quite alright, you could argue it's more readable this way. Only thing I don't understand is the |
Hey @markteekman, I hadn't noticed the empty tags but they must be a reformatting artifact. I only see them in that one component. Maybe the custom formatting is because your editor settings don't automatically format This is sort of embarrassing but I seem to have posted a longer line limit test when I posting my above example instead of the I'll get a pull request sorted to review. The reformatted svg example I actually meant to post as an example is this... {
previousPage ? (
<a href={previousPage} aria-label={`Go back to ${previousPage}`}>
<svg xmlns="http://www.w3.org/2000/svg" aria-hidden="true" width="32" height="32" viewBox="0 0 24 24">
<path
fill="none"
stroke="currentColor"
stroke-linecap="round"
stroke-linejoin="round"
stroke-width="2"
d="m14 7-5 5 5 5"
/>
</svg>
</a>
) : (
<span class="disabled">
<svg xmlns="http://www.w3.org/2000/svg" aria-hidden="true" width="32" height="32" viewBox="0 0 24 24">
<path
fill="none"
stroke="currentColor"
stroke-linecap="round"
stroke-linejoin="round"
stroke-width="2"
d="m14 7-5 5 5 5"
/>
</svg>
</span>
)
} |
Great @david-abell! Adding the prettier-plugin-astro makes sense, I forgot about that one 😅 I have some time to look at your PR, so I'll get on it right away! |
When I use the library I get the following error, I think that the library is missing typescript type definitions.
The text was updated successfully, but these errors were encountered: