4 posts tagged with "typings"

There has been a lot of discussion on Simplified Scripting in Nexus 3, especially on the Nexus Discord channel.

On the one hand, simplified scripting is useful for people who are not used to coding. They are not overwhelmed by an empty box and infinite amount of possibilities to do something wrong. Instead, they are presented with a slimmed down list of options that they can use and can fully concentrate on the "what" they want to do and most of the "how" is abstracted away. It gets them in the mindset of algorithmical thinking while not making them think about syntax and formal language.

But once they want to break outside the box of Simplified Scripting and the limited actions that are supported, some users have already created complex systems. They now need to convert that to traditional JavaScript, which can be a tedious and daunting process. Additionally, they need to learn coding syntax and formal language and look up the Nexus API for the same things they had already made.

Introducing a Converter

Since Simplified Scripting can be understood as an interpreted scripting language of sorts, it can also be converter (or transpiled) into actual JavaScript code.

While the resulting code is often overly complex (not all information, whether steps like variable expansion are needed, is available at transpilation time), it can serve as a good starting point to learn syntax and explore the Nexus API.

This release features the first version of a library that can do such conversions. It is not yet feature complete and misses transpilation support for more complex actions that require context (eg Goto, If, Repeat, Label) or rewrite the MUD output. But it is complete enough to convert simpler packages. Additionally, the release unblocks the development of its dependent project (see the GitHub project as well), a website that allows converting existing packages to a pure script version, compare these versions, and download the results.

Steps forward

I try to bring both the converter library and the NSSC forward in an even pace. However, if you have ideas that can improve either projects, please contact me in the Nexus Discord. I also welcome contributions to all my projects, but especially help in these two of my current focus areas would be greatly appreciated.

What else?

During the development, I noticed that some of the newer actions were missing from both the typings and the package builder. These projects were extended to include the new possibilities.

If you like the project, please consider leaving a star on the GitHub project and sponsoring me.

Part of what makes TypeScript so enjoyable for me is the ability for IDEs and tooling to check, whether functions, objects and properties you use actually exist. However, since TypeScript is interoperable with the vast JavaScript ecosystem which doesn't support the type system out of the box, away to add the information is required. Enter typings. This is a way to declare the typings of a JavaScript object through a number of helper files without adding functionality.

Since Nexus is written in plain JavaScript and doesn't publish any type information, the subproject @keneanung/iron-realms-nexus-typings was created. It is a ever expanding collection of typings for the different Nexus APIs and classes it uses.

The Problem

Writing the types itself is pretty straightforward since they mostly use standard TypeScript constructs. However, structuring them in a way that is logical and that makes the global nexusclient object available, is hard 8for me). TypeScript by default supports Module syntaxes only. After some trial and error, I found a way to support both the monorepo usecase of this repository as well as consuming the types in an external project like nssc.

What's Breaking?

Due to the restructuring, types for the different Nexus objects like Reflexes, Actions and so on now need to be imported like normal classes (eg. import {Reflex} from '@keneanung/irong-realms-nexus-typings') instead of using the nexusclient namespace. Functions like ui() or send_commands() on the namespace still work by siply using the namespace without any imports: nexusclient.send_commands().

If you like the project, please consider leaving a star on the GitHub project and sponsoring me.

Howdy! This release was brought to you by an unforseen change on the Nexus side, which caused external UI tabs to be saved with the settings. That in itself wouldn't be too bad if it didn't mean that critical information that made the tab an UI element was lost. So on restoring these UI elements, the whole UI would crash and all you were left with is a blank screen.

This release contains a workaround for the issue. Since the UI is already broken for most of you, the workaround I used to keep my packages was to log in via a mobile app (Android in my case, iOS should work as well, but not the browser!), gointo the settings, then Custom Tabs and remove the npkg_ui tab. If you then log into the webbrowser, the package manager should work on the browser and allow you to update the package manager with the workaround.

Additional Changes

Since I was working with the webpack entrypoint anyways, I extended the Nexus typings by a few interfaces and functions to remove eslint and TypeScript magical comments.

If you like the project, please consider leaving a star on the GitHub project and sponsoring me.

This is the first release of the scripts within the new monorepo structure. For some background about the changes see here. Were're here now to celebrate the release itself! ❤️

New Script: Queue Manager

The queue manager introduced with this release is meant to make it easier to use the in-game queueing with your scripts. It tracks the queue, allows you to queue client-side commands and tries to integrate as seamlessly as possible with external queue sources.

This release does not allow for the foll flexibility of the in-game queueing yet (like prepending or adding at certain places in the queue), but it should be enough to vet the implementation. For more details, please refer to the documentation.

Developer Documentation

Due to the switch to the monorepo structure, I added a lot of additional developer documentation, like READMEs, a Code of Conduct and Contribution Guidelines. Please have a look!

More Infrastructure Changes

In addition to the overall layout change of the repository and all linked changes, I also switch from dependabot to renovate. This hopefully further decreases the dependency maintenance burden as dependency upgrades are now bundled together. Currently, this still has some kinks to straighten out, but I'm sure we will get there.

Other Changes

Most packages should now export their classes as a global library, which webpack then can use to avoid bundling all the code with yours. This is still untested, so expect further changes in that area.

Additionally, quite a few of the linter and test rules saw some harmonization, which prompted a few non-code changes to follow best practices.

If you like the project, please consider leaving a star on the GitHub project and sponsoring me.