How to use TypeScript with Eleventy? #577
Comments
|
Have you tried it yourself, yet? |
|
As far as I understand, the only current way to do so is through using the In theory, this works fine, but it presents a huge burden on our workload, as you now have to wait for 2 processes to happen in sequence before you can see any change propagate. I've recently gotten into the same situation when trying to use Svelte as a template engine for specific parts of my site, and would love to know if there's any specific implementation that mitigates this problem. My current implementation is as follow:
Problems:
NOTE: I know this is not related directly to Typescript, but as I'm dealing with transpilation much like you'd with TS, this might be of help. If needed, I can transfer the svelte discussion somewhere else 🤗 |
|
Hmm, stabbing in the dark here, but a few things that might stoke the fire:
That's odd, I haven't noticed this. Maybe I experience the same and simply haven't noticed, or maybe there's something else going on. |
I symlinked some :-) |
|
Wow #117 has 53 upvotes! |
|
I would definitely say this is dependent on #117 but I’ll go ahead and put this into the enhancement queue since it’s kind of a standalone thing. |
zachleat
added
enhancement
needs-votes
|
This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. View the enhancement backlog here. Don’t forget to upvote the top comment with 👍! |
|
@jevets Thanks for the thought process, I ended up settling for parallel Rollup and PostCSS processes that paste files in a folder that Eleventy picks up with pass-through copy. It's working nicely, but the Would be amazing if you could try reproducing it o/ |
|
In addition to the other tweaks with Alas, it does not trigger rebuilds for changes to the config (I think that's expected?), but it does build everything correctly… and you can use one small hack to be able to watch for changes to (That blog post will probably be late this week or sometime next week; feel free to just poke at the source in the meantime. It includes type defs for most of the API surface of Eleventy! I plan to get those on DefinitelyTyped by the end of the year.) |
That would be much much appreciated, @chriskrycho ! |
|
I’ll see if I can get them up. Just as I’m moving off of 11ty to my own thing! (Not 11ty’s fault. Just finally getting a handle on doing exactly what I’ve wanted to for half a decade!) |
|
As I get more experience with using JSDoc annotations for typechecking using |
|
Hey @Ryuno-Ki is there any update on including a type declaration file, so TypeScript users can |
|
Do feel free to steal from mine, which are still mostly accurate but now a bit out of date. (I haven’t switched off of 11ty, but I also haven’t had time to publish those in any way, and likely won’t—just not at or anywhere near the top of my priority list). (I'm unsubscribing from this, so won't see further conversation in general.) |
|
Hmm, I tried saving that file as Not that I expect anyone to look at my code, but here's my current setup, if anyone has 2 minutes to look it over for something I might be missing. My Eleventy build code is in |
|
@paulshryock without looking at your project, take a look at the |
|
Yeah I checked out those files. I'm already using |
|
I was in need of this very setup, after some trial and error I got it all working pretty nicely. TypeScript doesn't necessarily have to be supported by 11ty for people to make use of it. I wrote a very short article on how I went about it below: There's also a fully kitted out starter that I mention in the article: |
|
Nice writeup @jhukdev! For my use case I'm importing 11ty programmatically, and that's where the missing type information becomes a problem. import Eleventy from '@11ty/eleventy'
(async function() {
const elev = new Eleventy()
await elev.write()
})() |
|
fwiw I've had success using esbuild-runner to run the project (mostly) out of the box. You'll probably need to use the I use this Then you can invoke 11ty with: |
|
Here is an 11ty template in typescript in case anyone needs it (I didn't see it in any of the links in this thread -- though I might have missed it): https://github.com/c0derabbit/eleventy-starter-typescript |
|
I did want to reference this one too using the new addExtension API |
|
@zachleat Ahh this is an interesting solution! I hadn't considered this approach, thanks! 👍 |
|
This was bugging me so I shipped a drop-in solution. I was able to get a fair bit covered. Methods are JSDoc annotated with relative links to online documentation on the 11ty website. There is no support for plugin types, ie: In any sense, these configuration supported typings should help in productivity. Install
As per #577 (comment) the module can be consumed using pnpm add @panoply/11tyhttps://github.com/panoply/11ty Live ExampleScreen.Recording.2022-05-15.at.06.55.43.mov |
Thanks @panoply! Any work towards getting types for Eleventy is much appreciated, and I'm sure many people will find this useful.
Why wouldn't typings just be included in Eleventy core via a pull request, or added to a potential Having some types for just the eleventy config object in a 3rd-party repo maintained by 1 person, using the global package name @panoply I'm not against having your own personal wrapper for any project, but couldn't it be namespaced like Edit: Instead of "And is potentially typo-squatting", I should have said something like "And could have the unintended result of becoming a typo-squatting vulnerability". I didn't mean to directly or indirectly imply any malicious activity from @panopoly. Forgive me for coming off a little too harsh in my above comment. |
When leveraging an Types are assumed and should not require JSDoc comment annotations, hence the wrapper. The same logic is employed with other projects, for example in Rollup you can import
Agreed. It is important to note that given the module is directly focused for 11ty the thought process is completely targeted towards the project users. In addition, the module has a peer on (
Again, I'd be happy to pass it over. My intentions are anything but "typo-squatting" and far more focused on actionable steps to bring type support into Eleventy. This issue per-say has seen no traction and it is rather difficult to get PR's merged or considered. |
|
Registry name |
|
@panoply, I apologize if it seemed like my feathers were rustled or if I was telling you what to do. I have no affiliation with Eleventy (I'm just a user), and was just trying to voice concerns for further discussion. I hear what you're saying about the technical implementation--how your approach as-is seems to work better for now as a module wrapper. Your explanation was helpful.
I think anything that brings us closer to TypeScript support is a good thing, so I just want to reiterate my thanks for your hard work on this--and hopefully assure you that I wasn't trying to call you out or accuse you of doing anything wrong. (Reading back over my initial comment; it may have sounded harsher than I meant--sorry!)
I wasn't aware of this--did you try opening a PR to add the relevant type declarations in this repo? |
|
@paulshryock No apologies needed, I didn't think you were calling me out, but hearing how you voiced your concerns, I didn't want folks to think I had malicious intent or anything like this. My thoughts in using the
So 11ty is somewhat known for this and personally, I do not consider it a bad thing, I mean the less contributions sometimes the better the code. Look at the success of esbuild and how Evan approaches his project, so I wouldn't want to bother core maintainers with something a frivolous as this. Previous discussions and issues relating to this have pretty much died out or gone stale. Though I could PR it wouldn't be fast tracked and folks in the past have made somewhat similar PR's or opened dialogue but nothing has come fruition. Shipping this as wrapper module allows users to simply |
|
Eventually it would be a good thing to have either TypeScript types and improved JSDoc annotations as part of Eleventy itself. Understandably popularity of Eleventy has grown a lot over the years, as the project slowly changed from a personal project of Zack to something more. Still, almost all of the code changes are made by him, so any major changes would need agreement from Zack. Problem with 3rd party types is that those often get outdated quite fast, even for projects with a reasonably low amount of changes. Question is also about who is the target audience. Even while the weekly downloads of When looking at https://github.com/11ty/eleventy/graphs/contributors statistics, it shows that there are ~70 contributors in total, and most of those are with ~1-4 commits in total (per person). Situation would be a bit different if there would be multiple active contributors to the main Eleventy codebase. Extensions have variety of contributors, but what matters here most is how main codebase is developed. We can't make any decisions on behalf of Zach. But we can ask for his opinions about the future directions of Eleventy. Understandably he has a bit more time & focus for the overall project at the moment, so it would be interesting to see where this goes in the future.
|
|
@d2s Given the current architecture shipping types without needing to reach for JSDocs annotations can only be realistically achieved by passing const Eleventy = require("@11ty/eleventy");
// Create an instance
const eleventy = new Eleventy()Those developers using the default class export (ie: programmatic control) can indeed benefit from DefinitelyTyped but it will not solve the issue for developers using the module.exports = function(eleventyConfig) {}Currently, folks who are leveraging comment JSDoc annotations need to do this: /**
* @type {import('@11ty/eleventy')}
*/
module.exports = function(eleventyConfig) {}Such an approach is extraneous and not necessarily fluent for a couple of reasons.
The simplest way to negate JSDoc annotation and also feed Type support is passing a function callback. This is a common practice across multiple projects, it also separates logic and keeps things clean, upkeep is easy and logic is kept separated from the core. This is to some degree why I went the
I don't necessarily agree here (well to an extent). The methods I'd argue a third party plugin to be less intimidating for folks to submit a PR opposed to DT. The simple approach here (IMO) is to keep this an opt-in, ship it under the @11ty org and allow the community or core maintainers to monitor its health. This way, the core codebase can exist and no breaking changes are imposed. Doing this: const eleventy = require('@panoply/11ty')
module.exports = eleventy(function(eleventyConfig) {
// etc etc
return {}
})Lifts the burden from the Eleventy maintainers, they can focus on the JS purity of the project and need not bother about merging or reviewing PR's on core code which are pertaining to types. Anyway, that is just my two cents and if the core team and @zachleat want I'd be happy to assist in maintaining such a module under the org. |
No, sorry. Had mental health issues end of last year and then got carried away (in between Covid and everything). |
Sorry to hear, and completely understandable -- it's been a hard few years for sure. No worries. |
|
In case it's helpful to folks stumbling upon this thread, I was not interested in letting TypeScript transpile assets for the end user's browser, as we already use a bundler for that, but I was interested in having Eleventy code itself (config, and all the things (filters, shortcodes, helper functions) it imports, in TypeScript). For this we created a little wrapper // @ts-check
// This is just a wrapper so we can have our real config in TypeScript.
require('ts-node').register({
files: true,
swc: true,
compilerOptions: {
module: 'commonjs',
},
})
// @ts-expect-error to avoid "An import path cannot end with a '.ts' extension. "
const { default: eleventyConfig } = require('./_eleventy/eleventyConfig.ts')
module.exports = eleventyConfigYou'll need at least From that moment on everything in I added types by @chriskrycho which were linked higher up this thread and adjusted them a little bit to type the 11ty ts config and to give our code an understanding of what our collections are, etc. It would certainly be cool if Eleventy at one point could natively load I guess a bigger dent would be made if Eleventy provided also support for typescript data files, perhaps via #2279, because this wrapper method gets unwieldy once we start it applying to dozens of files, and |
One more downside of this approach where I don't think you can manually add more files, such as |
I was wrong, I found In // We wrap the eleventy typescript configuration in the original `.eleventy.js` file
// but that means any changes to the eleventy config aren't picked up, unless we add this:
eleventyConfig.addWatchTarget(__dirname)
// ^-- i keep the ts config in an `_eleventy` directory with more files that the config imports,
// but you may need to change this to `__filename` if it's just a lonely typescript file in the
// root for instance |
|
Wanted to cross post this coming 2.0.0-canary.19 solution from @pspeter3 here https://www.11ty.dev/docs/languages/custom/#aliasing-an-existing-template-language Relatedly, I have been merging a few types PRs for the Eleventy.js file and configuration files from folks recently into core—appreciate help with those! |
|
Tried that approach just now to get TS Data Cascade files but for me it ended in: That's on: Without the changes suggested by that Gist, it just works, the Not sure what the best way to get more details on this error is |
@kvz, either add a file extension for your template or bump Eleventy to See more info: |
|
My third time looking at this, and finally, a simple end-to-end answer: If you want:
Then do this: .eleventy.ts tsconfig.json src/pages/index.11ty.tsx run commands: |
|
Official template syntax docs for TypeScript and JSX just shipped here: https://www.11ty.dev/docs/languages/typescript/ This also includes an approach to use TypeScript for your Eleventy configuration file too (as contributed by @danielrob above!) |
zachleat
removed
the
needs-votes
Are there examples of how to use TypeScript with Eleventy?
Would like to be able to use TS with 11ty.
The text was updated successfully, but these errors were encountered: