TypeScript support in core

[sneridagh]

So, let's put this on the table and discuss it during the Beethoven Sprint.

To be clear: I'm (still) far from being sold on TypeScript, and have profound doubts on how it could benefit Volto in short/mid term (as I always did). For a number of reasons:

• Plone/Volto developers base are not familiar with it,
• let alone old Plone community members who wants to adopt Volto for their next projects.
• The community lacks of "TypeScript Wizards(TM)" to rely on when things get weary.
• Problems derived from adding an additional abstraction layer to the equation outweighs all the possible benefits that it could bring, and a whole new category of errors (typings) to solve, instead of focusing in features and getting things done.
• "Type safety" is still a concept that, personally speaking, is overrated and often misunderstood by "hurray, my IDE autocompletes everything". Unit, acceptance testing and documentation are as important as "type safety".

However, once named the "cons", there are also some "pros".

• Best way to document code internally, signatures, props, config object, etc.
• Could be the entry point and the enabler of some other complex things.
• The whole ecosystem is migrating to it, and the typings permeate the IDEs and your code.
• Volto is becoming stable enough to start introducing it.

Summarising, the proposal is not to migrate Volto to TypeScript, but having the ability to use it here and there in core if appropriate in some specific areas to gain knowledge and confidence as a tool, and artefact, not as a must.

I know could be a drawback and might be chaotic to have some things in JS and others in TS. As said, let's discuss it during the sprint, and see how it goes.

/cc @mtoepfl I'd like to know your feedback about the PR, if you please could take a look, it would be great!

Regarding implementation details, I added a tsconfig.json, adding TypeScript support for .ts files only as Razzle already supports it. In the ESlint side, I replaced the (deprecated) babel-eslint with @babel/eslint-parser, and use the TypeScript ESlint parser only on the .ts files. So effectively this way Volto supports both JS and TS at the same time.

UPDATE: I fixed some ESlint issues that the new parser and rules was complaining about. The important changes related to this PR are in the root.

UPDATE (2023-04-17): I've managed to make the change non-breaking for 16 series: #4705 Undoubtedly, there could be backport issues still, but it's doable.

[netlify]

✅ Deploy Preview for volto ready!

Name	Link
🔨 Latest commit	24f98cb
🔍 Latest deploy log	https://app.netlify.com/sites/volto/deploys/65082d9935cc8500083ce6dd
😎 Deploy Preview	https://deploy-preview-4662--volto.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[pnicolli]

😃

• Plone/Volto developers base are not familiar with it,

Agreed that this is an issue, it is my main issue on this topic, the other ones are just smaller obstacles.

• let alone old Plone community members who wants to adopt Volto for their next projects.

All of these people can use JavaScript in their projects as they would today. Adopting TS in core does not mean forcing people to adopt it for projects that use Volto. It would just improve their developer experience actually.

• The community lacks of "TypeScript Wizards(TM)" to rely on when things get weary.

Well, we kind of often lacked in JavaScript experience in the community, and Volto is a simple enough case in my opinion for TypeScript not become a enormous problem. Also, typings can be rough and improved later, for possible complex situations.

• Problems derived from adding an additional abstraction layer to the equation outweighs all the possible benefits that it could bring, and a whole new category of errors (typings) to solve, instead of focusing in features and getting things done.

I believe you might be underestimating the benefits here, with blocks, config and api being the most complex things to work with and the ones that would benefit the most from TS.

• "Type safety" is still a concept that, personally speaking, is overrated and often misunderstood by "hurray, my IDE autocompletes everything". Unit, acceptance testing and documentation are as important as "type safety".

Yes, those things are crucial, TypeScript aims at being an addition to those, it is not there to allow us to remove tests or docs.
My preferred TS benefit is consistency in refactoring, something that has been done several times in this product.

However, once named the "cons", there are also some "pros".

• Best way to document code internally, signatures, props, config object, etc.
• Could be the entry point and the enabler of some other complex things.

Zod? 😃

• The whole ecosystem is migrating to it, and the typings permeate the IDEs and your code.
• Volto is becoming stable enough to start introducing it.

Actually it would have been more beneficial before being stable than after being stable, for the reasons explained above. But it's never too late, and Volto will never at perfect stability.

Summarising, the proposal is not to migrate Volto to TypeScript, but having the ability to use it here and there in core if appropriate in some specific areas to gain knowledge and confidence as a tool, and artefact, not as a must.

Imho, the goal should be to enable TS, yes, but with the long term dream to completely migrate, otherwise the benefits are cut in half (but still there).

I know could be a drawback and might be chaotic to have some things in JS and others in TS. As said, let's discuss it during the sprint, and see how it goes.

Regarding implementation details, I added a tsconfig.json, adding TypeScript support for .ts files only as Razzle already supports it. In the ESlint side, I replaced the (deprecated) babel-eslint with @babel/eslint-parser, and use the TypeScript ESlint parser only on the .ts files. So effectively this way Volto supports both JS and TS at the same time.

iirc this is basically the same we suggest in the docs, so it's perfectly fine by me

[mtoepfl]

Hey @sneridagh. Thanks for mentioning. I'm happy to read this message this evening.

I'm happy to revisit the changes I did on the sprints at the conference and push it to this branch.

I only had some problems with some export * from 'xxxx'; statements, but the rest looks really promising.

A problem is that you have to touch many files which are hard to merge if the modified files are changed by other pull requests. So a discussion/decision beforehand could save a lot of time.

I would love to answer questions on typings. Mostly it's very straight forward and easy to learn for app-parts. For some tweeks in "library"-parts, I'm sure, that there are many real "TypeScript Wizard" on the internet who will be happy to jump in and give feedback if needed.

I am interested to see the comments of the other core developers.

[mtoepfl]

@pnicolli:

My preferred TS benefit is consistency in refactoring, something

100% dito: eg. thinking of refactoring the fetch/redux logic

+1 for this and all other points you mentioned

[sneridagh]

@mtoepfl I knew you'd like it ;) I'd love to have the work you did during the last PC sprint!

Btw, could we have it separated from this PR? So we can keep this one as the PR that enables the support, then all the other related work.

I'd like also to have full ok and support from the Volto Team and hear all the feedback about it before proceeding.

Regarding the export X from Y problem, it's fixed.

[cypress]

Passing run #7177 ↗︎

0	577	20	0	0
⚠️ You've recorded test results over your free plan limit. Upgrade your plan to view test results.

Details:

Merge branch 'master' into typescript-support-in-core
Project: Volto	Commit: 87fe50464e
Status: Passed	Duration: 13:43 💡
Started: Sep 12, 2023 11:59 AM	Ended: Sep 12, 2023 12:13 PM

_{This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.}

[sneridagh]

@tiberiuichim if you have a moment, due to upgrades to the ESlint plugins, now react-hooks plugin is complaining about:

/Users/sneridagh/Development/plone/volto/src/components/manage/Blocks/Search/hocs/withQueryString.jsx
  18:11  warning  The 'indexes' logical expression could make the dependencies of useEffect Hook (at line 24) change on every render. Move it inside the useEffect callback. Alternatively, wrap the initialization of 'indexes' in its own useMemo() Hook  react-hooks/exhaustive-deps

✖ 1 problem (0 errors, 1 warning)

https://github.com/plone/volto/pull/4662/files#diff-fc8bdb4141e8455cee5f70633025f8027f1449a064b16bf87b3530d28ee2c0b2L18

Could you please take a look? Thanks!

[sneridagh]

@plone/volto-team I just realised of one thing.

Since I had to update ESlint to the latests version and I changed the parser to use @babel/eslint-parser, and I've updated all the ESlint plugins, it must be a breaking one (since now it reports more things than before, affecting all projects out there.

The CI is green for a project (but we don't have any .ts component yet), so we don't know how this will affect them. We'll have to see, but I expect some adjustments there too (at least jsconfig->tsconfig) changes.

Marking it as breaking change shouldn't be any problem at first sight, but that means that we won't be able to port anything TS based to 16... which is an important drawback...

Something to talk about during the sprint.

[sneridagh]

I've managed to make the change non-breaking for 16 series: #4705 Undoubtedly, there could be backport issues still, but it's doable.

[stevepiercy]

We need docs for this feature addition. Something like:

We got TypeScript! w00t! 🥳 🎈 

But you don't *have* to use it, you knuckle-dragging mouth breathing luddites.

Oh, OK, maybe not quite like that (which would be worse than no docs), but I'm sure y'all can improve upon it. 😜

[pnicolli]

Just a small comment, but LGTM.

[stevepiercy]

Minor English and MyST syntax, grammar, and style.

[sneridagh]

Decision Volto Team Meeting (2023-09-12): It will be included in Volto 17. However, it needs to be documented properly. @sneridagh commits himself to work on this during the PloneConf Sprint (and other documentation matters).

• How to use React TypeScript
• How to configure IDEs to support TypeScript
• Which are the limits of usage (if any) and the expectations (eg. no code would be migrated, it won't be mandatory for any code).
• How to handle backports to stable (if any).

[mtoepfl]

🎉 I'm going to join you at coming PloneConf Sprint.

I could try to cherry pick my changes of the PloneConf Sprint last year. Before I planned to write a benchmark for creating brains with many fields in metadata for ZCatalog. I feel it's getting over proportional slower in reading, when adding many fields to metadata. Maybe there ist a bottleneck. But finding this out should not take too long.

Is it possible to merge some of the refactoring pull requests to functional components before the Sprint?

[sneridagh]

@mtoepfl awesome! I might multiplex this and docs this year.

Could be that your changes overlap with this PR I made: #4949

We will have to merge them both and you review my crappy TS ;)

I can't wait!

[sneridagh]

@stevepiercy I made some additions to the docs, could you please take a look?

@pnicolli I tried this in existing projects and seems to work fine, even without changing the jsconfig->tsconfig so I guess we are good.

I updated the docs to reflect all that should be done in order to update a project to TS (which is acceptable).

[stevepiercy]

Mostly grammar and syntax fixes, but a question or two. This is great! Thank you!