Prebid.js: Possibility of Typescript support

Created on 8 Apr 2020  路  1Comment  路  Source: prebid/Prebid.js

Description

This ticket is to track interest in Typescript types for Prebid.js. Let me know if you think types would be useful in the ways that you use Prebid.js.

My initial thought is that we could start by typing the bid adapter interface as both a complement to the bid adapter unit tests as well as being additional documentation of that interface (would most likely stay up-to-date better than jsdoc types since it's verifiable with the typescript compiler).

Later on down the line we could choose to type things such as the public API (methods on the pbjs global). I doubt we'd ever start typing internal core code as there is much less value there and it would require a lot more effort.

Some things to consider in a typescript implementation:

  • Prebid.js will probably not be rewritten in typescript as that is a huge refactor.
  • Types could be added as ambient declarations within the prebid repo as .d.ts files that live along the relevant .js modules OR we could maintain a separate types repo within definitelytyped or in the prebid organization.
  • Bid adapters could be submitted as .ts files and we could update our webpack build to accommodate building both typescript or javascript files. This would be considered a backwards breaking change since it would break webpack builds outside of the prebid repo (such as people using prebid.js as an npm dependency) that assume all modules are javascript. Since it's backwards breaking we probably wouldn't do this until a major release down the line, which could take awhile if we choose to go this route.
  • We could accept bid adapters that are already pre-compiled to .js files as bid adapter submissions and the we could choose to either allow the .ts source files to live in this repo or require you to manage your own .ts source files and only allow generated code in this repo. Since we're still only including the generated .js code in the webpack build, this is not a backwards breaking change and could be implemented right away.

A proof of concept of the last method (submitting generated javascript with typescript source alongside) has been opened as a pull-request here: https://github.com/prebid/Prebid.js/pull/5056

If there's some other way of using types not listed here that you think could be beneficial please feel free to comment.

Other information

Previous ticket related to types: https://github.com/prebid/Prebid.js/issues/1122

adapter support intent to implement pinned

Most helpful comment

Thanks @snapwich for the detailed explanation. We use typescript for all our ad tags we build and provide our own set of types for prebid.js.

Prebid.js will probably not be rewritten in typescript as that is a huge refactor.

Airbnb released an interesting tool that might make this more feasible.

https://github.com/airbnb/ts-migrate

OR we could maintain a separate types repo within definitelytyped or in the prebid organization.

I would heavily favor hosting this inside the prebid repository. This ties the types much closer to the actual releases

Bid adapters could be submitted as .ts files and we could update our webpack build to accommodate building both typescript or javascript files. This would be considered a backwards breaking change since it would break webpack builds outside of the prebid repo (such as people using prebid.js as an npm dependency) that assume all modules are javascript. Since it's backwards breaking we probably wouldn't do this until a major release down the line, which could take awhile if we choose to go this route

That would be amazing. We had quite a few bugs, because of different formats things can have, e.g.

  • size definition: '300x250' or [300, 250] or [[300, 250]]`
  • bid adapter parameters had types, invalid types, no examples

I doubt we'd ever start typing internal core code as there is much less value there and it would require a lot more effort.

I wouldn't say that. There are quite a few _very_ complex modules with very complex data structures. I'm always having a hard time reading the code as the types are never clear nor have names. This makes it much harder for external publishers / advertisers to contribute.

So overall I think adapting typescript would be beneficial for

  • external contributions
  • bug rate
  • documentation effort
  • ease of adapter implementation
  • reduce of unit testing ( half of the unit tests check that the things you put in are transformed into another thing)

>All comments

Thanks @snapwich for the detailed explanation. We use typescript for all our ad tags we build and provide our own set of types for prebid.js.

Prebid.js will probably not be rewritten in typescript as that is a huge refactor.

Airbnb released an interesting tool that might make this more feasible.

https://github.com/airbnb/ts-migrate

OR we could maintain a separate types repo within definitelytyped or in the prebid organization.

I would heavily favor hosting this inside the prebid repository. This ties the types much closer to the actual releases

Bid adapters could be submitted as .ts files and we could update our webpack build to accommodate building both typescript or javascript files. This would be considered a backwards breaking change since it would break webpack builds outside of the prebid repo (such as people using prebid.js as an npm dependency) that assume all modules are javascript. Since it's backwards breaking we probably wouldn't do this until a major release down the line, which could take awhile if we choose to go this route

That would be amazing. We had quite a few bugs, because of different formats things can have, e.g.

  • size definition: '300x250' or [300, 250] or [[300, 250]]`
  • bid adapter parameters had types, invalid types, no examples

I doubt we'd ever start typing internal core code as there is much less value there and it would require a lot more effort.

I wouldn't say that. There are quite a few _very_ complex modules with very complex data structures. I'm always having a hard time reading the code as the types are never clear nor have names. This makes it much harder for external publishers / advertisers to contribute.

So overall I think adapting typescript would be beneficial for

  • external contributions
  • bug rate
  • documentation effort
  • ease of adapter implementation
  • reduce of unit testing ( half of the unit tests check that the things you put in are transformed into another thing)
Was this page helpful?
0 / 5 - 0 ratings

Related issues

mthazin picture mthazin  路  6Comments

dugwood picture dugwood  路  4Comments

mercuryyy picture mercuryyy  路  5Comments

Rubioli picture Rubioli  路  3Comments

whatisjasongoldstein picture whatisjasongoldstein  路  6Comments