Create and publish typescript package

[mart3323]

From #todo/jsmacros/14

14. if someone wants to figure out the best way to repackage the typescript docs for NPM publishing, that'd be great 🙂

Changes

For the npm package

1. Added README.md and package.json for the npm package
2. Removed version number from JsMacros.d.ts filename (for the npm package only)
3. Added new job in betabuild.yml to publish 0.0.0-sha (f.ex. 0.0.0-d3adb33)
4. Added new job in release.yml to publish a.b.c (f.ex. 1.7.0)

Unrelated

1. Fixed typing of Java.from()

Note on compatibility with main-1.19

The current 1.19 branch reports errors for basic scripts such as Chat.log("string") not because the packaging is wrong, but because the generated .d.ts file now contains the type _javatypes.java.lang.Object in a bunch of places.
For testing i put these changes directly on the 1.7.0 release and the packages produced from that version worked fine

[wagyourtail]

Publishing a package on npm permanently reserves that name+version combination, so i don't feel comfortable doing test deployments there

test publishing to @yourusername/JsMacrosTypes or something, and then I can change it when merging

[mart3323]

npm package names must be lowercase. Would /jsmacros-types be acceptable then?

[mart3323]

Updated branch typescript-package to latest main-1.19 (as of about half an hour ago)
Switched deployment to npm registry (buildrelease.yml tagged as latest by default, buildbeta.yml tagged as beta)
Currently published test versions are

@mart3323/jsmacros-types on npm
@mart3323/jsmacros-types@latest This branch, based on latest 1.19, bad types
@mart3323/jsmacros-types@beta This branch rebased onto 1.7.0, good types

[wagyourtail]

I have grabbed the @jsmacros org. want me to add you to it?

[mart3323]

Up to you - though keep in mind that as soon as we switch to the final package name, anything published (including from this unmerged MR) will become locked in. NPM does not allow editing/republishing to the same combination of package name and version number
source: https://docs.npmjs.com/policies/unpublish

[mart3323]

If/When this is otherwise ready to merge, i would like to clean up the history with a quick interactive rebase first

[wagyourtail]

yeah. I think the requested changes are wrapping up, feel free to add back the beta actually...
maybe peek at #72 and see if it's doing something better.

I haven't really done too much with npm, but I should've invited you to the org.

[mart3323]

Rebase complete. publish for beta reincluded

Added one final extra change - I noticed a comment in the build script was outdated

# This workflow contains a single job called "build"

so i deleted that.
Then i saw all the other comments also seem like they're just from an example file.

Since none of the other .yml files had comments like those, i figured i'd remove them from betabuild.yml as well to declutter it

[mart3323]

in #72, the only feature i spotted that is missing here is building a .tgz artifact. It feels unnecessary here, since
a) You can download the package from npm
b) If you're not using npm and just want to drop in the types, the tsconfig + header files work perfectly

but i also don't have experience with tgz files so I might just not be thinking of the right use cases
@Johannes7k75 If we publish to npm anyway, would there still be a reason to create a tgz for the artifacts as well?

[Johannes7k75]

The reason i include the package in the artifact is that i dont have to get the sha of the beta build.

[Johannes7k75]

But other than downloading the types as a .tgz and downloading the Mod at the same time, there is no other benefit