wave-play / robo.js Goto Github PK

Changeset: minor

This new docs command is to be a subcommand of generate.

npx @roboplay/sage generate docs

This will take the existing Robo project's manifest and automatically generate documentation files. For now, they should be in a generated DOCUMENTATION.md file containing all of the commands, events, context commands, etc along with their descriptions. It is safe to assume that each entry may or may not have a description, regardless of type.

Be sure to add a brief sentence above each type. Generate them as tables.

In the future, we'll make this more customizable and allow certain types of documentation to be inserted in existing markdown files, such as the main README.md the same way our All Contributors integration does things.

Changeset: minor

Leverage OpenAI's new vision models to allow bots to explain images!

Changeset: minor

Changeset: none

Changeset: none

I’m not yet sure how to achieve this while remaining neutral to package managers, but we should handle or at least warn developers when multiple copies of the framework are installed.

This most commonly occurs when you’re developing plugins locally using different versions of Robo.js or with NPM minus workspaces. This causes there to be uninitialized Clients, Flashcores, etc

Perhaps we can achieve this by attaching a value to the global object in the entry file (@roboplay/robo.js) and checking it there? Ideally, I’d like to automatically handle it, but the best we can do for now is at least warn, no?

Changeset: patch

When creating a new Robo via this command, we should pass down --robo-version that matches the current project's version of Robo.js. That way, we can ensure we avoid package manager hoisting issues right off the bat.

Changeset: patch

Either some sort of Cli Start and end hooks.

This way, we can make plugins that analyze memory usage as we start

Changeset: minor

As the title says, the old robo.config.* file will no longer be supported. We weren't sure if a config folder was the way to go at first, so we offered a more traditional option. This changed with the introduction of plugin config files, so now we're going all the way!

.config will still remain supported for a while yet, to give people time to transition, but we should at least include a warning about that.

Changeset: minor

It’s basically what the title says. When converting a project into TypeScript, the primary typescript is not added as a devDependency.

Changeset: patch

Changeset: patch

Changeset: minor

This was the original runtime before the new worker thread-based Spirit system was released in v0.8.0 and became the default in v0.9.0. The reason for switching was due to how inefficient it was with performance and resource consumption.

Now that we have gotten more data and feedback on this, it’s time to bid adieu to our old runtime powered by child processes. This will help us focus more on the default worker runtime and bring improvements to it without worrying about features working on both.

Templates/economy-bot

A new Sage CLI command to upgrade existing JavaScript Robo projects to TypeScript!

npx @roboplay/sage typescript

This should:

• Install @swc/core as a dev dependency.
• Generate a default tsconfig.json identical to the one generated by create-robo.
• Rename all existing .js file extensions to .ts.

Steps should be done in the same order as listed above to ensure early failures don't affect actual files, as those will be the last step. Avoid executing unnecessary steps such as already-install dependency and existing .ts extensions. If a tsconfig.json already exists but the contents don't match, inquire if it should be overwritten or left alone.

Changeset: minor

Changeset: minor

Changeset: minor
Blocked by: #88

Changeset: none

Changeset: minor

unable to set or get data using flashcore, undefined

Changeset: minor

Changeset: minor

Use the Jest library to create an integration test to verify that REST Endpoints work as they should.

Purpose

Don't test the API Plugin's internals, meaning the router, handler, etc. Instead, test the actual end result by making a dummy Robo for testing purposes. Set a dummy Discord token for now. Future versions of Robo.js won't even require Discord integration.

We want to verify that basic functionality always works as intended.

Preparation

1. Create a dummy Robo project with no commands nor events. Only the /api folder with about 5 different endpoints mimicking a general project. Use a variety of combinations so that we can test not only basic endpoints like /sign-in, but also nested routes like /users/:id/action. Feel free to make as many endpoints as you need to test things. 5 is not a strict requirement.

2. The test should run an exec (or spawn) call to run the robo build and then robo start commands in a specific port. You may need to run a setTimeout "sleep" for a few seconds to verify that the server is running first.

3. Once the server is up and running, the tests will need to make fetch calls to verify that the API endpoints are returning the intended results. Make sure you're on Node 18 or newer for this.

Tests

• GET, POST, PUT, PATCH, DELETE, OPTIONS, and HEAD should all work as intended.
• Headers passed in the request should all be available to the API endpoint.
• Query parameters should all be parsed (read) and available to the endpoint.
• Redirects should return as intended.
• Usage of the raw http objects (req.req and res.res) should be able to respond just as well as returning from the function would.
• Top level paths (/one) as well as deeper paths (/one/two/three) should all work.
• Path parameters (/users/:userId) should route as intended and make the param values available to the end user.
• Errors thrown inside API endpoints should not crash the API server.
• Endpoints should be able to send back custom headers.
• Request body should be available to the endpoints.
• Endpoints should be able to send back custom status codes.

Changeset: none

Changeset: minor

The ability would be able to access options more seamlessly inside slash commands.

Current method:

export default (interaction) => {
  const user = interaction.options?.get('test')?.user
  return `Hello ${user.username}`
}

New with command parameter:

export default (interaction, options) => {
  return `Hello ${options.user.username}`
}

The options parameter would basically be an object containing the options specified.

More importantly, we should have type safety for better TypeScript support as well as code autocomplete. This makes sense for Robo.js because we already have the same information included within the same file by convention:

import { CommandConfig, CommandOptions, createCommandConfig } from '@roboplay/robo.js'

export const config = createCommandConfig({
  options: [{
    name: 'test',
    type: 'user',
    required: true
  }]
} as const)

export default (interaction: CommandInteraction, options: CommandOptions<typeof config>) => {
  options.test // This would resolve to "User" - not undefined because we infer it from "required: true"
}

Unfortunately, the createCommandConfig helper function and as const become necessary to achieve this type safety.

The interaction object will be left alone, so existing Robos will continue working as always, and the current way of getting options will remain the same, so no breaking changes for this feature.

Changeset: minor

Changeset: none

Commands

• /mod audit - Audit a member's activity in the server
• /mod ban - Ban a member from the server
• /mod forgive - Forgive a member and clear their strikes
• /mod kick - Kick a member from the server
• /mod report - Report a member for something
• /mod setup - Sets up the moderation tools for the server
• /mod timeout - Times out a member for a specified amount of time
• /mod warn - Warns a member and adds a strike

Why these commands when they already exist as part of Discord?

Unlike Discord's built-in commands, these are more flexible with additional options such as anonymity. Each action will also trigger a log in the moderation logs channel and have side effects in the form of "strikes" or infractions.

Why the "/mod " prefix?

This forms distinction from the built-in commands and keeps things more organized. Furthermore, because we encourage developers making bots with Robo.js to use plugins, we can expect a higher quantity of commands compared to traditional bots. This prevents further conflict.

Context Commands

• Message: Report Anonymously - Same as /report except always anonymous and with context
• User: Audit - Same as /audit

Moderation Channels

• Audit Logs - A global way to track user activity, including edits, additions, deletions, etc.
• Moderator Logs - Every action taken by a moderator shows up here, whether that action was taken within the channel or not.
• Moderator Mail - Every time someone reports something, those reports show up here.

Permissions

Each command's default permissions is configured to be the same as the built-in equivalent. For example, to use the /mod ban command you must already have the permissions necessary to use the built-in /ban command. Additionally, none of these commands may be used in DMs.

Server admins may override default permissions as they see fit as long as Discord allows it.

Setup

Server mods or admins are expected to run the /mod setup command when first adding a bot containing this plugin into their server.

This command takes no options whatsoever. When run, the Robo will reply ephemerally with various components moderators can use to configure various settings. These are the configurable options:

• Moderation channels (select dropdown)
• Require confirmation
• Test mode

When setting up for the first time or when no moderation channels have been setup, there will also be an option to automatically create them with one button click.

"Require confirmation" is a toggle that makes it so that moderation actions require confirmation after execution. This may prevent accidental usage or usage with the wrong people.

"Test mode" makes it so you can try out these moderation features without any actual action taken. For example, you can test out /mod ban to verify the output without actually banning someone.

Changeset: minor

This command will take a Discord.js bot and convert it to Robo.js, or more specifically, create a new Robo.js project with the same commands and events as the Discord.js bot. This will be a great way to get people to try out Robo.js without having to start from scratch!

npx @roboplay/sage convert

Similar to the export command, this should create another folder adjacent to the Discord.js bot's folder. The new folder should be named robo-<original-name>. (just add a robo- prefix to the original name)

We should leverage create-robo to bootstrap a new project based on the original Discord.js bot. Remember to use Typescript if the original bot is written in Typescript by checking for either a tsconfig.json at the root or the typescript package in package.json. (dev dependencies most likely)

Don't try to make this perfect right away. For now, let's only focus on bots similar to that of the Discord.js guide. We may need to run original files through @swc/core to convert them to ESM first.

Events will be the tricky ones. Let's just start by sticking them in /src/events/_start as this will emulate Option 2 of the migration guide. It's kind of a hacky solution, but it's a start.

Make sure to strip out the client object from the original files. We don't need it anymore. Just make sure to include its options as part of the config/robo.mjs file. Those intents are very important.

Changeset: minor

Changeset: minor

Whenever you run robo build or robo build plugin, source maps are generated for their respective source files. This is useful for finding the actual source of issues rather than the compiled output.

However, this can potentially expose the names of the users building because the source paths are absolute. This is fine for normal Robos that no else else may get the compiled code for, but maybe not for plugins that get distributed publicly.

All official Robo plugins have been built via our CI Pipeline so we hadn't noticed until now that a wider community is building and distributing them. We should strip the working directory's parent path when building plugins to ensure privacy just in case.

Changeset: patch

Part of the benefit of handling CLI arguments ourselves is that we can now control how a command handler is used.

We should be able to pass string paths as the handler and have the CLI auto load it. This way, we only load what we need.

For example, the start command will no longer add stuff like the robo compiler into the module import cache, thus lowering memory consumption and reducing the likelyhood of bugs.

Changeset: minor

Sage CLI commands should be available via sage when Robo.js is installed.

npx sage upgrade

We won't actually bundle the entire CLI, but rather, alias npx @roboplay/sage as simply sage. This makes discoverability easier, ensures the latest version is always used, and lowers our bundle size!

Changeset: minor

There should be a new -rv --robo-version flag that allows users to specify what version of Robo.js to have pre-installed in their Robo.

Changeet: minor

Changeset: patch

NPM is quite bad at managing local dependencies, which is especially problematic for Robo.js at it is stateful at a global level. This makes installing and developing plugins locally a bad experience for developers because NPM decides to have multiple copies of Robo.js when there should only be one even for the same version.

Other package managers don't have this issue, and neither does NPM workspaces. Only NPM projects without workspaces have this issue, which is unfortunately going to be most people.

For projects using npm as their package manager and not using workspaces, we should install plugins via npx install-local instead of npm install during Sage CLI's export command, after the step where we ask if they would like to install the plugin locally. This will emulate "production" (registry) installs and prevent multiple copies of Robo.js from being installed. Only downside is that watch mode will no longer work this way, so be sure to include a warning to let people know.

Changeset: patch

Changeset: minor

Redo the way create-robo outputs content to be beautiful. ✨

Now that we're nearly out of the pre-release period, I feel like this CLI should become more beautiful to reflect widespread usage. Sticky progress bar, loading spinners, better plugin selection, etc.

Changeset: minor

Add docosaurus as the first docs version

Changeset: minor

Changeset: none

Changeset: minor

Changeset: minor

Changeset: minor
Blocked by: #88 #90

Hi I am getting that error when trying to install a plugin with bunx instead of npx. (it doesn't work with npx either).

Changeset: minor

Changeset: minor