JSDoc Style Type Linting with Comment Based Help #1658
Replies: 1 comment 2 replies
-
I think the big problem in all of this is the implicit type conversion that powershell does during runtime. It makes any system you can think of break apart as soon as you interact with code that hasn't been "type-annotated". Many of the benefits of static typing go away when my function needs a string, you pass a hashtable via some 3rd-party code and then i receive "System.Collections.Hashtable". Same goes with array packing/unpacking. You could honestly solve like 90% of the problem by just adding an engine flag to powershell that disables automatic type casting and an engine flag that disables automatic array/singular conversions and then use psscriptanalyzer to warn on places where the types (and pluralities) dont match perfectly. This doesn't help with functions that take pscustomobjects but you could imagine extending the type-annotation to require specific properties on the objects being passed in. As a note -- the lack of static typing causes a huge number of bugs in "powershell as an application" use-cases and it's the primary reason (secondary being performance) that we are actively removing powershell as an approved language for application code. |
Beta Was this translation helpful? Give feedback.
-
I've been thinking a lot how powerful and useful having a static type checker is in terms of intellisense and write-time fixes in tools like vscode, but I'm also OK with it being optional in a loose system like Powershell.
I've been thinking a lot about using the comment based help
.OUTPUTS
to define the type or type(s) a function can accept similar to how JSDoc works, and then have analyzer rules that error if the OUTPUT type of a function doesn't match the INPUT in another location. I imagine this has been thought about before so I wanted to post here for any prior art that exists before I maybe dive into it.Challenges:
PSDefaultParameterValues
maybe?Beta Was this translation helpful? Give feedback.
All reactions