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

Implement as TypeScript compiler transform #5

Open
grncdr opened this issue Nov 27, 2017 · 3 comments
Open

Implement as TypeScript compiler transform #5

grncdr opened this issue Nov 27, 2017 · 3 comments
Assignees

Comments

@grncdr
Copy link
Owner

grncdr commented Nov 27, 2017

The TypeScript compiler API supports transforms for a while now. It should be possible to implement the main functionality independent of webpack, and then expose it as a compiler transform as well as a webpack loader.

Keep an eye on microsoft/TypeScript#14419 to see if a common approach to using typescript with compiler transforms comes about.

@grncdr
Copy link
Owner Author

grncdr commented Nov 29, 2017

Turns out ts-loader already supports custom transformers 🎉

The way the first proof-of-concept was written is incredibly wasteful (running the typescript compiler twice) so I will definitely be rewriting this as a transformer and documenting how to use it with ts-loader.

@grncdr
Copy link
Owner Author

grncdr commented Nov 29, 2017

From looking at https://github.com/Igorbek/typescript-plugin-styled-components, the same is also true of awesome-typescript

@grncdr grncdr self-assigned this Nov 29, 2017
@grncdr
Copy link
Owner Author

grncdr commented Oct 6, 2018

Further thoughts on this:

  • @babel/preset-typescript is gaining in popularity, especially for development builds (where you really want the prop-types). It doesn't have any real type information though so this could never work in that environment.
  • prop-types in general appear to be falling out of favor for React.
  • The new context API has been released and use of static contextTypes is discouraged for new code.

Given the above, it doesn't make sense to sink a lot of effort into this project. I do like the idea of generating runtime validation code from static types, but I think it makes more sense to decouple this from the react prop-types infrastructure and require explicit validations. E.g.

import * as React from 'react'
import validate from 'ts-validate/validate' // a "marker" function, calls will be replaced by the transform

interface Props {
  foo: string
}

export default function MyComponent(props: Props) {
  validate(props) // compiler transform replaces this call with validation code generated from `Props`
  return <span>{props.foo}</span>
}

The ts-validate/validate package would export an empty function, so that code compiled without the transform will continue to run:

export default function validate(x: any) {}

(I'm fairly certain many minifiers will actually remove the function call entirely).

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

1 participant