build: Add deno typescript support to repository

[scarf005]

Summary

SUMMARY: Infrastructure "Add deno typescript support to repository"

Purpose of change

deno is a cross-platform runtime for running typescript in local environment. some of its benefits:

TypeScript out of the box
First-class support for TypeScript – no need to spend hours configuring things that break as soon as you update a dependency.

Great all-in-one tooling
Built in linter, code formatter, ability to build a self-contained executable, test runner, IDE integration, and more.

also, packages are imported from URL, making deno script very portable.

import { brightGreen } from "https://deno.land/std@0.182.0/fmt/colors.ts"

const world = "World"
console.log(`Hello, ${brightGreen(world)}!`)

some examples of deno's benefits in #2544:

• fully type safe argument parsing
• type definitions
• built in testing support
• comments allowd in config file (deno.jsonc)

Describe the solution

cherry-picked config from #2544

[olanti-p]

What is the purpose of this change?

Adding stuff just because it's "cool" is counterproductive, there's lots of "cool" stuff on the internet, you can't add everything.

New code should serve some immediate purpose, be it build, CI or tooling, otherwise it justs sit around and silently rots and wait for its turn the next time someone does a #2213

[scarf005]

its primary usage is to soft-deprecate outdated python tools/json_tools. new scripts are to be written in deno. deno was chosen not because it's cool, but because it makes maintaining tools written in them easier. lack of typings in current python scripts makes refactoring hard enough at the point that it'd be better to rewrite them from scratch, so was chosen deno.

why using python for new scripts may not be suitable for maintaining

• it lacks types. almost none of the codes are type hinted which makes maintaining the code diffcult.
• it's hard to type hint complex JSON structure in python without using 3rd party libraries like pydantic.
• it's hard to add tests to single-file python scripts. to test a script, 3rd party libraries like pytest are required, and they need specific directory structures in order for them to work.
• it's hard to import modules. python has hard rules on importing relative modules, so again, we need to completely modulize python scripts in order to even share a simple function.
• it's hard to manage dependencies. we do not have requirements.txt, and we need to manually install dependencies.

What could deno provide that python cannot do

• easily typing complex JSON types.
• testing built in, which improves robustness of tools. (Deno.test) can be included in a single script file. examples of their usage can be found in here (sights test, crossbow test)
• easy relative imports. unlike python, deno does not require project to be ran from a specific CWD.
• easy dependancy management. dependencies are imported from URL, so a program can be 'self-contained' inside a single file.
• it's trivial to import zod and provide type safe parsing of complex data structures and even generate JSON schemas.

in conclusion, usage of deno for toolings allows us to make type safe, portable and easy to maintain program.

for immediate usages, #2544 could be an example. i extracted only the config because i was planning to add some more tooling PRs written in deno besides #2544, and i didn't want to make these PRs all rely on #2544.

[olanti-p]

Ok, I can get the desire behind replacing python with typescript.

I don't necessarily agree with it: having the majority of the tooling in python is much better than having most of it in python and some parts in typescript. From googling around it seems that typescript is a bit behind python in popularity, but pure JS is way ahead, so we can expect contributors to know typescript to some extent same as we would with python. But having to know 1 language if you want to work with any tooling script is better than having to know 2.

Given the benefits and how outdated some python scripts are, I wouldn't be opposed if most or all our relevant scripts were to be switched to typescript (even if I would have to learn the language). Don't know what the other devs and contributors think though, or whether it impacts them.

for immediate usages, #2544 could be an example.

It should've been added in that PR then, along with documentation that explains what it is and how to use it. Config file for tooling that does not exist serves no purpose.

[scarf005]

i see. next time i will put all the related changes into single PR.

[Zireael07]

@olanti-p: Python is VERY popular (heck, we use it at my day job for a large Django website) BUT the lack of typing IS indeed often getting in the way.

JS is more popular than TS by a looong shot (it's pretty much THE language to use if you do ANY webdev at all). But it has the same problem as Python, with no types. Hence the bigger and more complex projects readily move to typescript.

[scarf005]

@Zireael07 yeah fully safe type python can be written using type hints but our scripts aren't written using any of these type hints.

[Coolthulhu]

it lacks types. almost none of the codes are type hinted which makes maintaining the code diffcult.

That's a pretty strong argument, I guess.

Still, it would be good to limit the number of languages as much as possible, to make setup easier.
How much effort is it to set up TS support on Windows in a way that will work with the build system (if needed)?

Would you be willing to write a doc on it?
Would it be easy enough that say, a tileset maker could follow it, despite having no knowledge of TS or any real programming for that matter?

What's the expected role of TS in the project? Just used for some parsing or general usage?
"How required" would it be to set it up to build a full build (tiles, sounds, translations, tests) in MSVC?

Is it supposed to replace Python or be used alongside?
I'd prefer replace, so that we don't have multiple scripting languages, but then someone would need to rewrite the scripts.

[scarf005]

How much effort is it to set up TS support on Windows in a way that will work with the build system (if needed)?

"How required" would it be to set it up to build a full build (tiles, sounds, translations, tests) in MSVC?

To run the scripts

Only one executable, deno (or deno.exe) (installation) is needed to setup the system. No additional step is required to set up formatter, tester, linter, benchmark tool, etc as deno has all of them bundled. Also, no node_modules are required as deno manages package using URL.

Make it with the build system

- uses: denoland/setup-deno@v1

it only takes one line to enable CI to use deno. https://github.com/denoland/setup-deno works with linux, windows and mac.

Would you be willing to write a doc on it?

Of course. it could take multiple PRs, however.

Would it be easy enough that say, a tileset maker could follow it, despite having no knowledge of TS or any real programming for that matter?

With some help (and some 3 hours of screensharing) @Kenan2000 could understand the scripts. I've also provided lots of guides and templates so beginners could edit the values and use.

What's the expected role of TS in the project? Just used for some parsing or general usage?

General usages. Can be used for any jobs that is not done by the game engine.

Is it supposed to replace Python or be used alongside?
I'd prefer replace, so that we don't have multiple scripting languages, but then someone would need to rewrite the scripts.

Is it supposed to replace Python or be used alongside?

The plan is to completely replace them. I've only rewritten cddatags.py for now. Might as well as ask for help to @DeltaEpsilon7787 as they are experienced in TS.