I read the GitHub issue all over again and I have some observations and questions (mostly questions :D)
What you propose would be a rewrite or something like "from this day forward all the new client code will be written with TS/Flow" ?
What happens to third party libraries that do not provide types or support for TS or Flow? Can they be used? Will they require the user to define all the unspecified types?
I really like the idea of using Visual Studio code's "ts-check", it could be a starting point helping to cleanup the code and migrate the code that's not on ES2015+ to it before one commits to TS or Flow.
Would Flow be less of an on/off switch transition? Would the path JS + ts-check -> JS + Flow -> TypeScript make sense?
At one point in the issue you say
it may (no guarantees) pique developers interest in contributing to dev.to OSS on the front-end more than say on a project that does not use TypeScript or Flow
The opposite could also happen: people willing to "casually" contribute (especially beginners who might not be knowledgeable of TS) might be deterred because TS is another whole of tools and syntax to learn because it's a separate language. We'll never know, which is probably a reason not to use this as a deciding factor after all :D
Currently the frontend code requires knowledge of ES5/ES2015+ and Preact at least. TS or Flow will help in having a more robust code base which is a great point in itself.
I'm a fan of Open Source and have a growing interest in serverless and edge computing. I'm not a big fan of spiders, but they're doing good work eating bugs. I also stream on Twitch.
Agreed that "the pique devs interest" shouldn't be a deciding factor. That was just a side note.
What you propose would be a rewrite or something like "from this day forward all the new client code will be written with TS/Flow" ?
You can enable TypeScript (TS) and all existing JS is considered valid in TS. From there you can incrementally add types. If we went the TypeScript route, I would probably promote TS with Babel since this is the easiest way to get started when migrating an existing codebase. Perhaps longterm the TypeScript compiler could be used. As far as I know there are only two things you can't do with the babel preset for TypeScript. const enums and the use of namespaces.
In regards to Flow, JS is valid there as well and types could be incrementally added that way as well.
What happens to third party libraries that do not provide types or support for TS or Flow? Can they be used? Will they require the user to define all the unspecified types?
3rd party libraries that are written in TypeScript do not have this issue as they ship (or should be shipping with their types). For everything else, there is a project called DefinitelyTyped.
This section tracks the health of the repository and publishing process
It may be helpful for contributors experiencing any issues with their PRs and packages.
This is the repo that allows you to install types via npm, e.g. npm install @types/axios-case-converter. Most 3rd party libraries have types for them thanks to the TypeScript community.
Nick Taylor
@nickytonline
@mikeal@AdamRackis@polotek@brianleroux The DefinitelyTyped project and the TS community have been helping a lot with missing types.Sure you run into issues sometimes where there are 3rd party packages missing types,but in my experience it is not that often.If you asked me back in 2015 when it was tsd, different story.
23:35 PM - 08 Apr 2019
00
For everything else, you can add types in your project for a 3rd party library, if necessary. Even better, put a PR up to DefinitelyTyped 😉
In regards to Flow they have 3rd party types as well via the flow-typed project, but not as many as TypeScript.
You can grab definitions directly from this GitHub repo, or you can use the CLI (currently in beta) to install a libdef for a given library:
$ yarn global add flow-typed
$ cd /path/to/my/project
$ yarn install
$ flow-typed install rxjs@5.0.x
'rxjs_v5.0.x.js' installed at /path/to/my/project/flow-typed/npm/rxjs_v5.0.x.js
Huh?
When you start a project with Flow, you likely want to use some third-party
libraries that were not written with Flow. By default, Flow will just ignore
these libraries leaving them untyped. As a result, Flow can't give errors if
you accidentally mis-use the library (nor will it be able to auto-complete the
library).
To address this, Flow supports
library definitions which allow
you to describe the interface of a module or library separate from the
implementation of that module/library.
I imagine the same thing can be done in Flow where if necessary, you can write types in your app that are missing for 3rd party apps. For all the Flow experts out there, please chime in.
I really like the idea of using Visual Studio code's "ts-check", it could be a starting point helping to cleanup the code and migrate the code that's not on ES2015+ to it before one commits to TS or Flow.
👍 if people are using VS Code. If not, I don't think this works.
Would Flow be less of on/off switch transition?
Not sure I understand the question. Do you mean is it less invasive than TypeScript?
I'm a fan of Open Source and have a growing interest in serverless and edge computing. I'm not a big fan of spiders, but they're doing good work eating bugs. I also stream on Twitch.
I read this post, largely agreed with it, but wanted to give this some thought.
I feel like my role needs to be that of allowing progress to happen while trying to re-enforce core values. My biggest opinion on frontend to this point has been to try to time the technology appropriately. I just haven't wanted to be on the front of too many waves even if they are great choices in and of themselves.
I'm probably down with this, and I feel like this could be a fairly community-led initiative. Me and the rest of the team just have to come up with a good shared understanding of the path forward.
We still have a whole bundle of JS that is definitely "legacy" at this point. So overdue to be made modern, so a pretty decent time to put some work into all of this, add better testing and make things more concrete on the frontend in general.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I read the GitHub issue all over again and I have some observations and questions (mostly questions :D)
What you propose would be a rewrite or something like "from this day forward all the new client code will be written with TS/Flow" ?
What happens to third party libraries that do not provide types or support for TS or Flow? Can they be used? Will they require the user to define all the unspecified types?
I really like the idea of using Visual Studio code's "ts-check", it could be a starting point helping to cleanup the code and migrate the code that's not on ES2015+ to it before one commits to TS or Flow.
Would Flow be less of an on/off switch transition? Would the path JS + ts-check -> JS + Flow -> TypeScript make sense?
At one point in the issue you say
The opposite could also happen: people willing to "casually" contribute (especially beginners who might not be knowledgeable of TS) might be deterred because TS is another whole of tools and syntax to learn because it's a separate language. We'll never know, which is probably a reason not to use this as a deciding factor after all :D
Currently the frontend code requires knowledge of ES5/ES2015+ and Preact at least. TS or Flow will help in having a more robust code base which is a great point in itself.
I left more questions than answers, sorry :D
Agreed that "the pique devs interest" shouldn't be a deciding factor. That was just a side note.
You can enable TypeScript (TS) and all existing JS is considered valid in TS. From there you can incrementally add types. If we went the TypeScript route, I would probably promote TS with Babel since this is the easiest way to get started when migrating an existing codebase. Perhaps longterm the TypeScript compiler could be used. As far as I know there are only two things you can't do with the babel preset for TypeScript. const enums and the use of namespaces.
In regards to Flow, JS is valid there as well and types could be incrementally added that way as well.
3rd party libraries that are written in TypeScript do not have this issue as they ship (or should be shipping with their types). For everything else, there is a project called DefinitelyTyped.
The repository for high quality TypeScript type definitions.
DefinitelyTyped
Also see the definitelytyped.org website, although information in this README is more up-to-date.
You can also read this README in Spanish, Korean, and Russian!
Current status
This section tracks the health of the repository and publishing process It may be helpful for contributors experiencing any issues with their PRs and packages.
If anything here seems wrong, or any of the above are failing, please raise an issue in the DefinitelyTyped Gitter channel.
What are declaration files?
See the TypeScript handbook.
How do I get them?
npm
This is the preferred method. This is only available for TypeScript 2.0+ users. For example:
The types should then be automatically included by the…
This is the repo that allows you to install types via npm, e.g.
npm install @types/axios-case-converter. Most 3rd party libraries have types for them thanks to the TypeScript community.For everything else, you can add types in your project for a 3rd party library, if necessary. Even better, put a PR up to DefinitelyTyped 😉
In regards to Flow they have 3rd party types as well via the flow-typed project, but not as many as TypeScript.
A central repository for Flow library definitions
flow-typedis a repository of third-party library interface definitions for use with Flow.You can grab definitions directly from this GitHub repo, or you can use the CLI (currently in beta) to install a libdef for a given library:
Huh?
When you start a project with Flow, you likely want to use some third-party libraries that were not written with Flow. By default, Flow will just ignore these libraries leaving them untyped. As a result, Flow can't give errors if you accidentally mis-use the library (nor will it be able to auto-complete the library).
To address this, Flow supports library definitions which allow you to describe the interface of a module or library separate from the implementation of that module/library.
The
flow-typedrepo is a collection…I imagine the same thing can be done in Flow where if necessary, you can write types in your app that are missing for 3rd party apps. For all the Flow experts out there, please chime in.
👍 if people are using VS Code. If not, I don't think this works.
Not sure I understand the question. Do you mean is it less invasive than TypeScript?
If the transition would be more gradual
They'd be the same in term of doing things gradually.
BTW thanks for the explanations :)
I read this post, largely agreed with it, but wanted to give this some thought.
I feel like my role needs to be that of allowing progress to happen while trying to re-enforce core values. My biggest opinion on frontend to this point has been to try to time the technology appropriately. I just haven't wanted to be on the front of too many waves even if they are great choices in and of themselves.
I'm probably down with this, and I feel like this could be a fairly community-led initiative. Me and the rest of the team just have to come up with a good shared understanding of the path forward.
We still have a whole bundle of JS that is definitely "legacy" at this point. So overdue to be made modern, so a pretty decent time to put some work into all of this, add better testing and make things more concrete on the frontend in general.