Skip to main content

· 3 min read

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.

· 2 min read

You have a type

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.

· 2 min read

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.

· 2 min read

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.

· 3 min read

Man tapping microphone

Test, test... Is this thing on? Aehm...

Since the infrastructure seems to be up and running, it is time to tell you why we moved.

Why I Combined Multiple Independent Repositories into a Monorepo for Enhanced Script Management

Today, I want to share my personal journey of merging multiple independent repositories into a monorepo for better script management. It's not about convincing you that monorepos are the holy grail, but rather about sharing why I made this decision and the benefits I experienced. So, let's dive in!

Tired of Update Chaos

I used to manage my scripts across different repositories. Every time I needed to make updates or coordinate changes, it felt like a never-ending battle. I spent much time syncing updates between repositories and trying to keep everything in check. It was exhausting, and I knew there had to be a better way.

Simplifying Dependency Nightmares

Dependency management was another pain point for me. Dealing with different repositories meant juggling multiple sets of dependencies and version requirements. And when it came to updating dependencies, it felt like a never-ending loop of repetitive tasks. It was time-consuming and frustrating.

The Call for Collaboration and Code Reuse

As developers, we thrive on collaboration and code reuse. However, with scripts scattered across various repositories, collaboration became a daunting task. Searching for shared code felt like searching for a needle in a haystack. Code duplication crept in, leading to inconsistencies and extra maintenance work. I knew there had to be a way to streamline collaboration and maximize code reuse.

Embracing the Monorepo Solution

After much consideration, I decided to take the plunge and combine all my independent repositories into a monorepo. And let me tell you, it was a game-changer!

Harmonious Updates

With my scripts residing in a single monorepo, orchestrating updates became a breeze. I no longer had to manually propagate changes between repositories. I could make modifications, run tests, and validate the impact across the entire codebase with ease. Updating became a streamlined process that saved me time and reduced the risk of inconsistencies.

Dependency Bliss

The monorepo approach revolutionized my dependency management. By centralizing all scripts, I gained better control over dependencies and versioning. I defined a shared set of dependencies and ensured compatibility across the codebase. Upgrading dependencies became a unified process, eliminating the headache of handling them separately for each repository. It made my life simpler and reduced the chances of version conflicts.

Collaborative Awesomeness

Bringing all my scripts together in a monorepo unleashed a new level of collaboration and code reuse. No more jumping between repositories to find the code I needed. It was all there, easily discoverable and accessible. Code duplication became a thing of the past, streamlining maintenance and ensuring consistency across the board.

Conclusion

That's my story of why I decided to combine multiple independent repositories into a monorepo for enhanced script management. It was a personal choice born out of the need for simplicity, efficiency, and better collaboration. While the monorepo approach may not be for everyone, it has undoubtedly transformed my development experience. If you're facing similar challenges, I encourage you to explore the monorepo approach and see if it's the right fit for you.

· One min read

This bugfix release fixes the issue that makes all actions for reflexes (eg calling scripts, coloring lines etc) disappear when installing a package through the package manager.

Additionally, version 0.2.2 fixes an issue in the website infrastructure.

I hope nobody lost important changes through this!

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

· 2 min read

I'm happy to announce that the project reached a huge milestone. It now handles dependencies of packages that are listed in package repository.

Handling dependencies

Whenever the package manager installs a package, it checks, whether it has other packages that are required for it to function correctly. These packages are first searched in the local package list. If they are installed, the package manager proceeds to install the original package as normal. If a dependency is not installed, the package manager will first install the dependency, before proceeding with the actual requested package installation.

The package manager will also make sure, that dependencies are listed in the correct order. This makes sure that the initialization of a package is only attempted when all dependencies are already initialized. No more documenting "and make sure package A is above package B". This happens both after the installation and update of a package.

UI improvements

The UI also got some improvements. You can now show package details within the window, including version, description, dependencies and a link to the website.

package detail view

The UI main page got some layout imprvements by using icons instead of text for buttons, which makes the page much cleaner.

package list view

Closing words

If these features got you interested, please feel free to either open an issue about including your package in the package listing or contact me on the Achaea or Nexus discrod if you need more information. You can also send me a direct message.

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

· One min read

This release does not contain any changes to the code of the event bus itself. Rather, it facilitates improvements to the packaging, adding version and website information directly into the package.

Additionally, dependencies were updated.

Version 0.5.1 contained infrastructure fixes only.

If you find bugs, would like to see more features and discuss particular design choices, feel free to create a new issue to get in touch.

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

· One min read

This is the very first release of the Nexus Package Manager. This MVP (Minimal Viable Product), which contains only a bare minimum of features. These include a basic UI, the retrieval of package data from a remote location as well as installation, update and removal of packages. All of this functionality is also provided by the Nexus UI, with the exception of a package listing. So right now it can be used as a way to discover new packages.

Future plans include the tracking and installation of dependencies, version handling and notification of new updates for installed packages.

The success of this project is strongly linked with how extensive the list of available packages is. So, if you know of a package or have authored one yourself, please head over to https://github.com/keneanung/nexus-package-repository and either add the package via pull request or open an issue so I can add it.

v0.1.1 Infrastructure fix

This version bump was only for infrastructure fixes. The package was not modified.

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

· One min read

This release contains a number of small bits and bops here and there to finetune the package and give it some extra shine:

  • Fix a possible security issue due to prototype polution
  • Inject version number into loading log message
  • Add hack to get the Map class back
  • Move raising specialized gmcp events to the NXS package for improved visibility and document them

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