cinny icon indicating copy to clipboard operation
cinny copied to clipboard

Slowly allow typescript

Open C0ffeeCode opened this issue 2 years ago • 9 comments

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] I'm always frustrated when I want to participate in Cinny's development, but the code miss types.

  • Worse IDE recommendations
  • Forgetting to check types can result in unexpected behavior / bugs
  • Higher development effort / time since the previously mentioned issues are not solved

That makes it hard to understand, add and modify code. This slows development and thereby diminishes innovation.

Describe the solution you'd like

A clear and concise description of what you want to happen.

TypeScript is the solution to this problem. Allowing TS does NOT mean all the code needs to be modified. Typescript can be configured without any problems allowing JS code and implicit types, and more so a file could just be renamed to have the ".ts" file name extension and still work.

Reading TypeScript is no change to JavaScript developers but makes it easier. However, for developers used to typescript (such as me) it is really hard to understand plain JS.

I would recommend responding to this idea in the following order:

  • [ ] Configure toolchain to allow TS
    • #300
  • [ ] Allow contributors to write in TS if they choose to
  • [ ] Allow contributors to edit existing code to add typescript to the "/src/client/" code
    • Allows to use types in React components if wanted

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Not allowing typescript will scare and has scared potential contributors away. This has a negative impact on the future of this project.

Additional context

Add any other context or screenshots about the feature request here.

There have been several discussions already and the community seems to prefer TypeScript, to name a few...

  • https://github.com/ajbura/cinny/pull/45
  • https://matrix.to/#/!rgQbWTfsoUcbvEDAvs:matrix.org/$XnRsIUuSUHRpVQrMbBf3RSibMaesoJ0VZ2dKI_JgLEU?via=matrix.org&via=envs.net&via=kde.org and following messages

C0ffeeCode avatar Feb 03 '22 15:02 C0ffeeCode

IMHO we are at point where app need new features instead of investing that time converting existing code to Typescript and defining types (There's no point in using TS without the type definitions). The main focus right now is to make Cinny feature rich so that it could be adopted to be used by wide variety of users.

kfiven avatar Feb 04 '22 09:02 kfiven

I do agree with you. When writing this issue, I was already aware of previous statements of project leadership. However, many/most (or all?) dependencies of Cinny already have types available.

I want to embrace that it is not my intention to change existing code to Typescript for no further reason but to allow us contributors to use typescript. Therefore, the tsconfig in the PR (#300) is configured to be the least enforcing or, in other words, strict mode is disabled. This includes that:

  • allowJs = true, this allows us to keep all JS code without change but use typescript if desired
  • strict = false: Do not enforce the usage of Typescript features/rules neither in JS nor TS files
    • ".js" files can be renamed to ".ts" and the additions a developer wants to make can be written in TypeScript without needing further changes to existing (untouched) code.

In other words, nobody (I do not) has the intention to rewrite all the existing code. (However, if you want me to, I would be happy to help) But it allows us to keep the whole Cinny code more readable and easier to understand while adding new features. In total this does not take more time than continuing as before but takes less because it gives us developers a better way to understand the code, so we can write the code quicker and be more productive in the same time span.

Established contributors to this project might have a good overview of the code, but for people, including people with experience, it is harder to understand at first and takes a lot of time to get accustomed to the code. This scares people/developers, potential contributors wanting to invest their time into this project to add new features away and therefore harms this project's innovation.

Thanks for reading this long text ;)

C0ffeeCode avatar Feb 04 '22 15:02 C0ffeeCode

I don't think this decision between typescript and feature richness is exclusive. One does not exclude the other, as some people may want to add new features and others may be more interested in contributing typescript code or improving the codebase in general.

Litom avatar Feb 04 '22 17:02 Litom

Indeed. TypeScript makes it easier to add new features. Allowing TypeScript does not mean disallowing new plain JavaScript code.

C0ffeeCode avatar Feb 04 '22 18:02 C0ffeeCode

Indeed. TypeScript makes it easier to add new features. Allowing TypeScript does not mean disallowing new plain JavaScript code.

Of course this too. But my point was rather that there are probably developers who would contribute to the codebase with Typescript who would otherwise contribute nothing at all. IMO this would not infer with the overall goal of getting new features implemented.

Litom avatar Feb 05 '22 02:02 Litom

Is this issue and PR still worth be opened?

From an outsider's point of view and following the discussed advantages and incovenients of using TypeScript, the community seems not to have embraced this technology?

dimitri-bourreau avatar Mar 08 '22 18:03 dimitri-bourreau

If some people do not like to write Typescript, accepting this issue & PR will not effect them. Everyone who can read JS can read TS, and people who want can write TS to archive a better development experience for both themselves and other devs.

Yes, I do think this issue and PR should remain opened and considered or accepted as I think it would be a good step to make Cinny's code even better.

We cannot embrace the advantages of Typescript here yet, because this project does not accept it at the moment.

C0ffeeCode avatar Mar 10 '22 16:03 C0ffeeCode

TS can eliminate bugs early in development, while it may "slow down" feature progression, a sufficiently clean codebase (type-checked with TS) can prevent many classes of bugs, its a tradeoff.

JS SDK wasn't TS for the longest time, and only until recently (in the lifetime of JS SDK) did they move all of its codebase over to TS

ShadowJonathan avatar Apr 04 '22 16:04 ShadowJonathan

I'm working on a client myself, with TS, and I can say the SDK is not TS-ready. I have a few // @ts-ignore because of wrong types (mostly about events name, but not only).

dimitri-bourreau avatar Apr 05 '22 08:04 dimitri-bourreau

It seems like this is going to be addressed in #1023

C0ffeeCode avatar Dec 20 '22 14:12 C0ffeeCode

I want to try to do this, anyone was already on this?

asukaminato0721 avatar Feb 07 '23 12:02 asukaminato0721