Proposal: Built-in TypeScript support

[ehs5]

Hey SuperOffice team,

I think I speak for my colleagues and myself when I say that we are very excited about the upcoming transition from CRMScript to JavaScript.

While there are many benefits, I also see some potential pitfalls in this move from a statically, strongly typed language to a dynamically, weakly typed language. To mitigate the potential risks of writing error-prone code in JavaScript due to its type unpredictability, I think integrating TypeScript support directly into CRMScript 2.0 is not only a handy, but a necessary feature.

Why not just set up TypeScript locally and paste the transpiled JavaScript code into SuperOffice?
I don’t see this approach working very well in practice. This would require every developer to set up and maintain a TypeScript environment for each of our customers locally, which is a big shift from how easy it is to directly do small changes in the CRMScript editor today. It will create overhead that does not exist today, and there could be cases we won’t have access to the original TypeScript code.
Worse off, what if someone decides to edit the transpiled JavaScript code directly in the CRMScript 2.0 editor? The change might not be noticed, and then you risk someone with the TypeScript repo transpiling new JavaScript code and overwriting changes done in the editor.

I’m afraid this approach is not viable, and will in practice mean we are not going to use TypeScript, despite its upsides. That's why I'm rather proposing built-in TypeScript support:

Built-in TypeScript workflow proposal:

1. The developer writes TypeScript code directly in the CRMScript 2.0 editor (or paste directly from their local editor if they want). The editor should have built in TypeScript support (syntax highlighting, type checking etc).
2. Upon clicking the “Save script” button, SuperOffice sends the code to a transpiler and JavaScript is returned.
3. Both the TypeScript and the transpiled JavaScript code are visible in separate editor tabs.
4. When running the code, SuperOffice runs the transpiled JavaScript code.

Regards,
Espen Steen
Cloud Connection AS

[SuperOfficeDevNet]

Thanks for your feedback @ehs5! 💯

Agreed, TypeScript support out of the box would be nice. This has been discussed and considered from the very beginning.
The CRMScript editor is not VS Code... and therefore does not support type checking as you experience in a real IDE like VS Code. Assuming Typescript is supported, type checking would only occur on a Save/Apply - similar to today.

This project is still in its' very early stages, so it has a ways to go and evolve. We still have a mountain of steps to climb, and none so trivial as including a tsconfig, calling the tsc and storing both the source and the result.

When this does go live, there will not be an option to create new CRMScripts with the existing language. So if JavaScript is all we support, that will be the only option available.

As I said, it's still early days, and the only sure thing at the moment is the backend will be NodeJS - not Deno or Dun.

See the CRMScript 2.0: A Paradigm Shift in SuperOffice Customization for more details.

Best regards, and keep the feedback coming!

[ehs5]

I also brought up "use TS locally and paste transpiled JS code into the editor" because it's a natural approach to take when wanting to use TS. But for the reasons I outlined, sadly I don't think it's going to work in real day to day scenarios.

I agree that JavaScript is more familiar, even with the popularity of TypeScript now. But the way I think about it is that having TypeScript support would not exclude being able to write plain JavaScript in CRMScript 2.0. If someone wants to write plain JavaScript even if you had TypeScript support, let them. 😄 JavaScript is obviously what's going to run in Node in the end anyways.

Thanks for listening!

[ejfasting]

Hello,

I've looked at this today.

There are alternatives to writing typescript, and i believe JSDoc would be a good alternative.

It would require an extra step to transpile ts into js, and everything comes with a cost (either in NOK or in performance). It makes the most sense to skip this step all together, if possible.

With JSDoc we would get the best of both worlds, and it would be interesting to hear your thoughts on this (?)
I can make some examples you can test with if you are unfamiliar with how JSDoc works.

Note: jsdoc is made for documentation, but some open source projects have actually moved from typescript -> jsdoc+js because it gives you most of the things you need. Look up 'svelte' and their argument for this move/migration

/eivind

[ehs5]

Hi again!

Good suggestion. I had already considered it before your post actually. I'm familiar with JSDoc, though I haven't used it myself. I'm also aware of the Svelte situation.

JSDoc is certainly a better alternative than writing JavaScript without type annotations, so in the absence of TypeScript support, I think it's likely I would use it (and hopefully my colleagues as well).

Obviously, JSDoc has the big pro of having no transpilation step, but I still think TypeScript is a better way to write code. Personally, JSDoc seems very comment-verbose to me and lacks important TypeScript features such as interfaces and enums.

As I understand it, Svelte moved to JSDoc for the source code of Svelte itself, due to issues they had with building and testing. Users of Svelte can still, and are still encouraged to use TypeScript when building Svelte applications. From what I've seen, the discussion around Svelte and TypeScript seems to be blown way out of proportion.

TypeScript really is an industry standard at this point, with more developers using TypeScript alone than JavaScript alone. So maybe JavaScript isn't that more familiar than TypeScript for the majority after all..

Espen

[ejfasting]

Hello,

I wanted to give an update in this thread, as others might ask the same question.

Our initial research looks promising, as we are able to compile to JS without much trouble, but still need to figure out how/where we store the JS (for now its just a new column in the scripts-table), so that we dont have to compile on every execution. We also need to test the workflow, and decide if this comes with a performance hit (it does not look like it at this point)..

Still it's a big step in this direction, and we thank you for bringing this up! :)

//Eivind

[ehs5]

Awesome! I'm very glad to hear you're trying out this direction. 😀

And yes, transpiling TS to JS every execution wouldn't make sense and is guaranteed to have too much overhead, so saving the transpiled JS code somewhere is completely in line with what I proposed initially.

[ejfasting]

Closing this discussion, based on recent news