misode / brigadier-ts

TypeScript port of Mojang/brigadier
MIT License
18 stars 5 forks source link

Thankyou so much! #1

Closed ryantheleach closed 4 years ago

ryantheleach commented 4 years ago

I was just thinking about porting Brig to ts, you absolute legend.

How close is this to complete?

misode commented 4 years ago

Most of the features are done, and I'm currently working on the suggestions. I'm also not completely sure how to handle argument types like longs and doubles since these are all represented by number in TypeScript, so feel free to give feedback about the decisions I've made so far.

ryantheleach commented 4 years ago

Personally, I'd attempt to make sure they work as Java does, and (in addition) create 'number' types as well, (but this may be more work then it's worth).

That way people who are using it to validate existing MC stuff can do so, and anyone using it as a 'familiar friend' after working with in in Java, can use something that feels a little more TS/JS native for their projects.

For reference, https://docs.nativescript.org/core-concepts/android-runtime/marshalling/java-to-js NativeScript only cares about Longs.

https://www.scala-js.org/doc/interoperability/types.html places some restrictions on types that contain less range then integers.

ryantheleach commented 4 years ago

For what it's worth, I'm tempted to try to port some of the utilities in https://github.com/lucko/commodore to Brig-ts

misode commented 4 years ago

@ryantheleach I'm not too familiar with that utility. What features specifically are worth having that are not in Mojang/brigadier?

ryantheleach commented 4 years ago

I wouldn't put them in brig-ts directly, but having a text form / parser that works on both java and ts? That would be pretty powerful. I think the rest of the features are minimal, and unable to be ported due to dependencies of MC/Bukkit.

See the section labelled Using commodore's .commodore file format https://github.com/lucko/commodore/blob/master/README.md

Once you have that, I could see a third library, implementing sending those over websockets when they updates, and having 'remote' / cached tab completion suggestions.

So you could literally connect brig-ts as a remote console, have a protocol for sharing the definitions, then remotely resolve the suggestions that can't be resolved locally.

misode commented 4 years ago

@ryantheleach I had a look at the commodore format, but it confuses me a little. While it does show the structure of the command tree very nicely, where are you supposed to define the code to run at each node? When you define the structure in code, you use lambdas.

The same is the case with the command registry from vanilla. It only has "executable": true.

ryantheleach commented 4 years ago

@misode I havn't had a chance to play with it in earnest, I've only just managed to setup a (rough) tests setup after several hours of learning TS / testing / VSCode setups. I'll let you know when I have more. (https://github.com/ryantheleach/brigadier-ts/tree/tests) Don't pull this yet, but feel free to check it out, / tell me if I'm doing something that rubs you the wrong way. I expect it will be a PR in due course. I just want to cleanup some of the packages first, and expect I'll be force-pushing to that branch until I get it right.

I'm not entirely happy that the launch.json for vscode has to call mocha directly, rather then using a launch script / task, or the npm task. But I relented to get the tests working via examples.

My current intention is to teach myself Brig, TS (although I'm also learning it professionally), and TDD/BDD in TS via writing tests for you, if you were interested in pulling them eventually.

As for choice of testing framework, Mocha and Chai seemed pretty standard, with good vscode extension support, I intend on adding test-coverage eventually.