ΝΙΚΟΛΑΣ
ΝΙΚΟΛΑΣ
I'll sort! let me version bump Æsthetic.
Ideally, you'd want use a declaration opposed to relying upon jsdoc annotation typings. The reason for this is because there are restrictions apparent and underlying limitations with jsdoc type enhancements....
Haven't seen unjs. Very basic approach, excluding the analysis for determining whether executing in a CJS/ESM environment would be _something_ like the below (untested and excluding varying gotchas) but general...
Hi folks, [11ty.ts](https://github.com/panoply/e11ty/tree/master/packages/11ty.ts) now supports the v3.0.0 API in its entirety, with all relevant documentation references and descriptions available. You can consume it via the [NPM registry](https://www.npmjs.com/package/11ty.ts): ```bash add 11ty.ts...
I've touched on this in #3296. As of now, unless the roadmap specifies otherwise, Typings _should_ be utilizing a standardized `defineConfig` approach. Given the current architecture, full-featured type support without...
Hey @Zearin, See https://github.com/11ty/eleventy/issues/3296 and specifically the `defineConfig` tactic. JSDoc annotations are covered with plugin support applied, along with documentation references in descriptives.
@Zearin, I apologize for not providing a more thorough response in previous comments. I had a busy weekend. To elaborate: using `defineConfig` is a syntactic sugar that allows for isolated...
I feel as if converting the entire project would be hugely problematic downstream. I love TypeScript but large projects like 11ty owe a lot of it's success to being pure....
I hear you, truly. Broadly speaking, I agree. It’s been a while since I last reviewed this codebase at length, but if memory serves, there are several overloaded function signatures...
@stevenvachon This is not really related to the issue. The discussion is about TS conversion of the Eleventy codebase, definitional sugar would only get one so far, you'd only end...