Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Planning Discussion for a move to TypeScript #252

Closed
duluca opened this issue May 26, 2017 · 2 comments
Closed

Planning Discussion for a move to TypeScript #252

duluca opened this issue May 26, 2017 · 2 comments

Comments

@duluca
Copy link
Contributor

duluca commented May 26, 2017

This is a planning discussion thread. Comments may be used to share code snippets and ideas or to add/correct pros/cons list.

Plan

  • Propose Interfaces that can be implemented in an unintrusive way so Type Definitions can be auto generated.
  • Identify and document challenging areas of the code base, along with a TypeScript code snippet that overcomes the challenge (i.e. function overloading https://www.typescriptlang.org/docs/handbook/functions.html, default parameters, Interface inheritance, constructor, nested generics)

Pros

  • Reduces amount of dev tools required, i.e. babel wouldn't be needed as transpiler anymore
  • Helps dom support with TypeScript's robust transpiling support for ES8 to ES3.
  • More maintainable code base using generics and type information
  • JavaScript developers consuming testdouble in js can benefit from type definitions, inline documentation and auto-complete
  • TypeScript developers consuming testdouble in ts can benefit from rich generics support
  • Type definitions would be automatically generated and wouldn't have to be manually maintained

Cons

  • A rewrite is a rewrite is a rewrite: a phased approached could be developed to ease the transition (i.e. Typed Interfaces to proxy existing JavaScript implementations)
  • Risky, testdouble depends on JavaScript quirks and single threaded execution to guess what the developer means by pulling the last item on the stack. A plugin may be required to provide such features to developers. While this would greatly reduce complexity of the codebase and open it up for even richer features. However, this in turn increases development and continued maintenance effort.
@duluca
Copy link
Contributor Author

duluca commented Jul 30, 2017

@searls Here's a good intro to creating TypeScript-based npm packages: https://dev.to/dkundel/writing-a-nodejs-module-in-typescript

Here's a TypeScript library starter that encapsulates best practices for creating packages that can target node and the browser which is what's needed for this project: https://github.com/Hotell/typescript-lib-starter

I'm going to update my TypeScript library https://github.com/duluca/documentts/ to test out the config and report back the findings.

@searls
Copy link
Member

searls commented Mar 24, 2018

Closing this issue since technically we have migrated to typescript, even though 99% of the code files are still .js

@searls searls closed this as completed Mar 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants