Refactoring working JavaScript code to satisfy limitations in TypeScript.
Everything is fine.
I am being productive.
This is productivity.
26 replies
make it work
make it ~~right~~ the same
make it ~~fast~~ slower@zachleat Is it open-source? I might be able to help. I've been doing TS for almost 12 years, so maybe I can help you find a way to keep your JS code and still use TS ^_^
@loucyx I may take you up on that if I get too far gone! For now I’m venting 😅
@pauleveritt @zachleat Sure, if it's an open-source thing, I don't mind taking a look. I don't take responsibility in my reaction if I spot `any`s in said code 🤣
@zachleat FTR, I hit that this week trying to get `new Eleventy()` and `eleventy.config.*s` working in Vitest. Some of your code really wants `.js` as suffix. But more likely...it's my stack.
@pauleveritt I’m refactoring Eleventy.js and the Configuration API right now to work better with TypeScript, fwiw
@zachleat Lovely. I am really, really excited about the possibility and documenting it. I just worry the issue is one-step-too-obscure.
If I made a tiny reproducible repo, would that be good or bad? (Bad because I'm making you look at something.)
@pauleveritt Happy to have a look!
@zachleat Here's a repo. If you'd like, I can make a quick video walkthrough if that's more efficient. https://github.com/pauleveritt/eleventy-test-config
-
@zachleat to be honest, doing this opened a new perspective of how much overcomplicated stuff JS allows you to do without thinking, which is not a great thing... regular solutions are usually covered by TS, and in other cases you can always use an escape hatch of ts-expect-error or type casting...
@brawaru I get it but it’s failing on pretty basic JS patterns so far. If I change the Array type to object, it passes without error.
@zachleat is this VS Code? I noticed a completely different error in TypeScript playground, which I also spotted on the screenie: you forgot the generic type parameter for Array. Seems to work for me like this: https://www.typescriptlang.org/play/?filetype=js#code/MYGwhgzhAEAqCmEAu0DeBYAUASGAewDtkAnAV2CT2IAoBKNLbbJACwEsIA6YxeJOgNyMAvlkY8IfOgxzYA9ACoF0AAJIAngAd4aAILFiYdQB5U0AmAC28AFzQSbAgHNowgHzDoCuY2bsumiCkTo4wALzQANoAukI4ophY0MnQigpJKV6qmmCGlmgOzp4W1hkp3oxgACZVAApBIQTUJfD0GLI8SKTEBNCsHJyBwaGDpBAs1GYtrrRx2AkJWPAAHppUKGYIyK4CQA
@brawaru Using TypeScript v5.5.4 in VS Code yeah.
@zachleat oh I see the the error locally, exactly what I suspected: TypeScript cannot really do magic of analysing the code flow deeply so it sees that `this.plugins` is not initialised in the constructor, but that you also define `this.plugins` in other place, so it consider it potentially `undefined`. You can simply initialise `plugins` at the top of the class to tell TS ‘trust me bro, it's there and it's never `undefined`’ (even though if forget to call `reset` in constructor, it will be 💀)
@brawaru yeah, that’s basically the approach I ended up with. This style of unnecessary code modification is what I’m now referring to as TypeScript slop 😅