You wouldn't implement an interface per say. You would implement a JSDoc type annotation which you can then attach to a doc string for a function input or return.
Next time you try to use that function the tooling (VS Code) will highlight the Type required by it as both documentation and a dynamic check - this fn input is missing X property.
Imagine it as a TS light version, where tooling and docs helps you write well-documented typed code that isn't checked for validity at compilation.
All the logic that is important is typed: all inputs, outputs. Each function is documented in terms of the program IO and what it should do and why (description).
There's no typed guard rails in place. You could pass an object that doesnt follow a type, but with team agreements, reviews, testing, and diligence you wouldn't. In TS you bypass process because the compiler does those checks for you.
To actually force runtime compliance to types and further get to a statically typed vision I used object validation schema. Each complex fn input would have a schema and we would validate against that.
In such a way you have some typing, documentation, and some static typing.
Since JS was never build with types or static typing as a first class citizen (like other languages are) there's less friction in scenarios where JS is too multifaceted or loose. This is the "have your cake and ear it" reply: you have types, documentation, runtime type checks for what matters, but you stay native to JS and avoid full static typing, remove the need for TS compiler.