Proposal: Add first-party core support for TypeScript configuration, data, and template files #3616
Comments
zachleat
changed the title
|
Some good info here too: https://2ality.com/2025/01/nodejs-strip-type.html |
zachleat
added
the
needs-votes
Robust type signatures would be a huge boon for me — I was looking at Eleventy last week for a project that's outgrowing Zola but found the lack of type signatures very frustrating to use.I almost wrote a big issue/proposal for this just last week, but decided against it. I'm not finding many alternatives to eleventy that look very appealing, though, so here I am :) Robust type signatures would be a huge boon for me — I was working through pauleveritt/eleventy-tsx, but I found working with TSX for layouts really challenging. When I write a component like this: export function MainLayout(props: any): JSX.Element {
return (
<html lang="en">
<head>
<title>{props.title}</title>
</head>
<body>
<Heading name={props.title} />
{props.content}
</body>
</html>
);
}
export const render = MainLayout;The A good example is the I find reliable and rich type information really critical when I'm writing software, and was pretty sad that I couldn't leverage them here. I understand some of the data is dynamic, but some of it is guaranteed by Eleventy — I think TypeScript lets you express things like "there's a |
In preparation for Node.js stable to ship TypeScript stripping as an unflagged feature https://nodejs.org/api/typescript.html
We already provide support for TypeScript via
tsx, documented here: https://www.11ty.dev/docs/languages/typescript/Default Configuration File Names
eleventy.config.tseleventy.config.mtseleventy.config.ctsDefault Data File Names
*.11tydata.ts*.11tydata.mts*.11tydata.ctsDefault TypeScript Template File Names
*.11ty.ts*.11ty.mts*.11ty.ctsDependency Tree Mapping
See https://github.com/11ty/eleventy-dependency-tree-esm and https://github.com/11ty/eleventy-dependency-tree for existing solutions.
The text was updated successfully, but these errors were encountered: