A github release is the same as a branch.
It creates a tag, which is essentially the same as a branch but not cluttering it up. Branches are used for new features being worked on etc.
You could create some CI using Github Action and Foreman (or aftman once it’s complete) to run rojo build
and then publish the .rbxm/rbxmx file to the releases
Version 1.1.0
The next version of StudioCLI is released! Featuring live syntax highlighting and a new package manager command, there’s no reason to not upgrade!
Please update the plugin to get the latest features.
You can read more about this release here.
I have seen a lot of CLI plugins lack an important feature: scripts! Instead of manually typing out commands every time I want to do something, I should be able to quickly run a script that automates the process. I should never have to add a custom command and wait for it to be approved and released. Most CLI plugins just tell you to write the script in lua and then manually execute it.
also please add ability to make custom aliases for commands thanks
Aliases were always supported but recently broke so I never mentioned this feature. It will be fixed next update.
I will be adding Profiles (inspired from Powershell) in the next update as well but I think you mean creating functions through the Terminal (Like if I typed function st { npm start }
in Powershell)
Some Ideas
- Startup file, like
.bashrc
or.zshrc
to allow users to create startup scripts, themes, and other settings. @comsurg 's idea of command aliases can be added in this startup script, just like bash/zsh. - Be able to “dev install” a package. Unlike normal installing, this is a temporary install in it’s out environment for developers to test their package. OR this could also be a way for users to install betas/nightly/unstable releases of packages.
Powershell-like Profiles will be added in v1.2.0 to take care of custom functions/aliases & startup commands but I will definitely consider this idea of a configuration.
Although this is a great idea, I don’t know how I could make this work. One idea I considered is installing the package but removing it on place shutdown (but there’s no event for that afaik). Could you explain how this could be achieved?
This is a plugin, right? If so, you can save data using plugin:SetSetting()
. If this is the case, during a dev installation, two things can happen:
-
- The plugin is saved to the actual plugin library where fully installed plugins are, you can tag it as “DEV” or something, and ignore it while saving data.
-
- The plugin is saved in it’s own developer environment, as long as the saving system doesn’t check there, the plugin should naturally be swept away once the user closes studio/exits that game.
No, I don’t mean functions or “profiles”. By “scripts” I mean files/scripts that I can put anywhere in the data model and then run using the terminal.
Ideally, the scripts shouldn’t use Lua and should instead have commands that will be executed as if I typed them in the CLI.
Typing in the scripts in the CLI would be inconvenient unless you make a text editor for your CLI, and I would rather use the built-in text editor
I finally got a chance to mess around with this plugin and it’s pretty nice. One thing I would really like to see is autoscrolling to the bottom of the scrolling frame so I don’t have to manually scroll down which is annoying. Also if clicking anywhere on the console would focus the text box it would be much more user friendly.
Finally I think the package manager needs more work. It makes more sense if packages were grabbed from a GitHub repo or gist that way developers don’t need to update their packages in two places. This also gives you the ability to integrate some sort of version control.
Packages should contain some sort of data to integrate properly with StudioCLI. The way you do this is up to you but it makes the most sense as a top level module. Maybe something like a package.lua
file?
For example:
- SomePackage (Instance – Doesn’t really matter what it is as long as
package.lua
is a direct child)- package (ModuleScript)
-- package.lua
-- Just provide some data to the package manager
return {
id = 'some-package',
name = 'Some Package',
version = '1.0.0',
}
You could then support commands like:
rbx info some-package
Some Package (some-package) @ v1.0.0
Just some ideas as I think this plugin has a lot of potential! Really great work
I agree that the package manager needs some work, but I don’t currently know of a way to grab files off GitHub. About the package.lua
thing, I’ll start adding more functionality to the package manager in v1.3.0.
Here’s a link to get you started.
GitHub has a nice API for working with repositories. You’ll notice in the data it sends back there’s download_url
key which provides a url to the raw content of a file. You can write a recursive function to generate these files and luckily Roblox allows up to 500 HTTP requests per minute.
If I have the time I might make a pull request to StudioCLI implementing this feature.
Version 1.2.0
Second major update this week! v1.2.0 is released along with new features such as profiles, configuration files, scripts, and a few bug fixes as well.
Please update the plugin to get the latest features.
You can read more about this release here.
Fixed a minor bug where if no config.cli
or profile.cli
existed the plugin would not start.
Version bumped to: v1.2.1
Version 1.3.0
GIT SUPPORT!!!
This update adds a whole suite of git tools, such as git add/reset
, git commit
, git push
(for remote repos), and much, much more!
You are also now able to clone any repository by using git clone USERNAME/REPO_NAME
!
Please update the plugin to get the latest features.
Interesting plug-in, I might use it later, does it automatically unpack files such as rbxm or rbxlx?
No, afaik binary and XML files don’t have a general way to decode and it’d be ridiculously difficult to create a binary decoder.
Forgot to send the full release notes for v1.3.0, here is the link.
- Scratch-To-Lua
- $EXEPATH that works like how $PATH & bin folders work on UNIX systems - for storing runnable executables
- “preview {id}” to preview images from the command line
- NOT SURE: rojo from the command line
- NOT SURE: More language interpreters (rn there’s only lua because of loadstring)
- A VSCode-like interface that can be prompted with “code {path}”
- Extra miscellaneous functions, like an HTML hr for the cli
0 voters
If an idea you have isn’t on the list, you can just reply to this message with your idea.