Prebid.js: Prebid 1.0 - static type checking

[matthewlane]

Tracking issue for integrating static type checking in Prebid.js, likely using either TypeScript or Flow

[ptomasroos]

I would prefer Flow!

[ETNOL]

+1 to Typescript. Having used both, Typescript's language services that support IDE/text editor integration are far superior. Flow does have better type inference at the expense of the ability to still write dynamic objects if desired (NoImplicitAny & StrictNullChecks options make this optional in Typescript).

Typescript makes for easier conversions of codebases by allowing lazy integration into an existing code. It requires only a build step to add Typescript to an existing codebase. It also has a significantly larger community in both the development side (measurable by blog posts and releases) and the support side (measurable by StackOverflow questions).

I also believe there are around 10x as many library definitions in Typescript. These def. files make API discovery effortless in comparison to hunting through documentation. Flow's Flow-typed show ~210 libraries vs Typescript's DefinitelyTyped repo of 2,971 libraries. Typescript's number is probably larger assuming some definition files exist in NPM's @types library that don't exist in DefinitelyTyped.

No offense to Flow users. Its a great type system! But for now, it is lacking too much in community support and development to be chosen over Typescript.

[dbemiller]

Not sure how recent this is... but I was trying to educate myself and stumbled on this comparison slideshow.

Does modern TypeScript still assume that parametric types are covariant? See Slide 21-26. If so, that's a pretty glaring error in the design of the type system... Invariance (Java-style) is a much more sensible choice if they didn't want to expose those choices to the programmer.

[ETNOL]

@dbemiller AFAIK that is still a problem in TS. It definitely seems like a terrible oversight and should definitely be counted as a con for TS. I would still strongly suggest the pros over Flow outweigh that concern.

[protonate]

Proposed
Use JSDoc as a type linter

Following discussion with some members of core team, an alternate proposal is to use jsdoc for a linter-style type check that can throw errors in IDEs or during builds but doesn't change JS syntax or file formats.

Work on Prebid 1.0 should be scoped to those architecture changes required to support features identified on the roadmap, with consideration of refactors for FP, build system, dev support and such targeted for Prebid 1.x. Using JSDoc leverages a tool we have already to begin working with the ideas of a type system while focusing on delivery of 1.0 features.

[dbemiller]

TypeScript doesn't sound too bad... but JSDoc still seems better to me.

Looking through the TypeScript docs, the vast majority of the features are native in ES6+ anyway. Some things (like Types) are nice to have, but the rest of the features dilute them such that the power-to-weight ratio of the framework as a whole seems pretty low.

The Prebid build system is quite complex (and buggy!) already.

• Failed unit tests return the wrong line numbers in error messages.
• Code coverage operates on the transpiled code.
• We just switched over to eslint as a code quality validator. Linting Typescript would require something else to help keep code quality high.

These issues are hard to fix due to the complexity of the build system. Adding Typescript or Flow would make them even harder.

We're in the process right now of better automating the build & validation, to speed up the Prebid release cycle. The more complicated the build, the harder that becomes.

Typescript's buggy implementation of generics bothers me--perhaps more than it should. If a language's main benefit is type safety, but it didn't build the type system properly, I have a hard time getting behind it.

---

I like the fact that Flow did the type system properly, and doesn't carry all the feature-overhead that is now native in ES6+. The small community is a bit of a worry... but I would still support it in spite of that if it proved to solve Prebid's problems better than jsdocs, and we were certain that it'd play nicely with the rest of the linting/testing tools in the build.

---

I also find myself wondering: what problems is Prebid development facing that people are looking at Types to fix for them? These are some of the answers I've heard so far:

1. _I hate trying to figure out which properties need to exist on an object._ Modern IDEs let you ctrl/click through JSDocs to quickly find the definitions
2. _Am I calling this method with the right params?_ IDEs can be configured to warn you if you're breaking the JSDoc contract.
3. _Which methods are part of the public API?_ documentation.js can generate API docs on the command line.

I love types... I really do. I just can't justify recommending them for prebid, given the size of the project and the number of issues that the build & validation scripts already have.

[ptomasroos]

I still think Flow gives better feedback quicker for the entire codebase. Here's a article that explain is quite well. http://thejameskyle.com/adopting-flow-and-typescript.html

[mkendall07]

We have decided not to implement a full fledge static system into prebid.js at this time. Instead, each function and type should be defined using JSDoc notation.