Chris Thomas

> Yes that would be nice for users to have a linter that check if the feature is supported or not, another way around would be to verify the code...

I haven't had a chance to take a look at the enum stuff yet. This is more of a nice-to-have so I wouldn't put it too far up the priority...

Well there two main things here. Well 3 if you count the string literals, but thats for another issue. The thing that caught me a little off guard was that...

I should have actually created a bug for the prototype not being there, rather than the eslint rule

Created a separate issue for the prototype https://github.com/dagger/dagger/issues/7446

That all sounds good. Were you thinking of doing it as an `eslint` rule or something bespoke? If you do it as a lint rule, I would probably publish it...

> Yeah I would like to do it as eslint rules, I've never work on that kind of thing but I'm sure there's nice doc explaining how to do that....

Have you thought of using [JSDoc](https://jsdoc.app/) for some of this? This is already used in the JS/TS ecosystem to provide more information about types / properties ![CleanShot 2024-10-11 at 18...

Using `JSDoc` has the added benefit of being read by IDEs, so that would provide a much nicer DX

I am very excited for this. Wanted to point out some incorrect assumptions with this though. > 💡 interface keyword will not be supported yet since it's pretty confusing with...