Script Editor - Better Analysis and Luau-Powered Upgrades

Hi developers,

We’re rolling a suite of new Script Editor features into Beta. This post provides an overview of them all but each has its own beta feature toggle. You can turn on any or all or none of them. You have the power! (N.B. all Luau-powered features work better with the “Scripts Are Non-Strict By Default” Beta Feature ON!)

Better Script Editor Linting

The Script Analysis widget and the logic used for linting have been upgraded. There are no major changes here but many bug fixes and more intuitive behavior. Every linting error will now link to helpful documentation.

Luau-Powered Type Hover

For any --!strict or --!nonstrict Scripts, hovering over any variable will now display the type in a helpful tooltip. The hover popup can also be invoked from the keyboard using (Shift + Cmd + i).

This feature works better with the “Scripts Are Non-Strict By Default” Beta Feature ON!

A tooltip appears when hovering over local variable abc, showing it's type as boolean

A tooltip appears when hovering over function foo(), showing that a number argument is expected but none is given

Luau-Powered Go To Declaration

The Go To Declaration (Cmd+F12) function is now being driven using Luau type inference when it is available. This makes the function faster and more accurate. As an example of what is possible, you can now right-click on and go to the declaration of table properties, even ones that were required from different modules.

This feature works better with the “Scripts Are Non-Strict By Default” Beta Feature ON!

Luau-Powered Script Function Filter

Similar to Go To Declaration, the Script Function Filter (Opt+F) is now being driven by Luau type inference when it is available. It will show all named functions in the current script with the function’s name, parameters and types.

This feature works better with the “Scripts Are Non-Strict By Default” Beta Feature ON!

Many thanks to @yohooyohoo, @HugoBLH, @swmaniac, @1ceF1y, @cruiser_forever, @iriszh, and @windy0724 for making Scripting spark joy!


This topic was automatically opened after 17 minutes.

This post was flagged by the community and is temporarily hidden.


These are some great features, glad to see more user friendly additions.


I love what you’re doing with the editor! Not having to get the types of variables through errors is a blessing. The function filter seems interesting enough too. Things are looking up for the editor. However, it’s not all sunshine and rainbows.

Some change that was made to the script editor within the last 24 hours has caused major issues for a plugin that I’m writing. After doing a bit of debugging I found that for whatever reason, SomeScript:GetPropertyChangedSignal("Source") fires incredibly slowly compared to how fast it used to fire and some pattern matching has completely broken as evident by me not touching it at all and it becoming non functioning. Was there any significant changes to specific control characters used or something?

This morning has been a huge headache for me trying to figure out what went wrong. :pensive:

There is a much larger issue going on that I didn’t notice at first. I thought Roblox changed control characters or something which isnt a huge deal because patterns can be changed, however I cant change the way the source is set.

I used a plugin to print my script’s source and it appears that the code is functioning as intended, but the editor IMMEDIATELY reverts the entire change. It takes less than .001 seconds to get reverted which is pretty odd.

Roblox changed the way a script’s source is set which completely breaks my gsub which is looking for specific syntax and I have no idea how to fix it.


Love the function filter, glad to see the built in script editor continues to become more accessible to users! Although my game is set up with Rojo and we often work in VSC, using the script editor every once in a while on other projects is no longer a drag.


It’s awesome that a feature I was thinking of just yesterday would be great to have on Roblox gets announced the next day! The time I will save knowing where that function is declared from where it’s called would be much less stressful while reading through other’s code I am not familiar with!

Thanks! :slight_smile:


Great! This will make Roblox studio easier for new scripters.
Quick question though: I am unfamiliar with this “opt” key, is it the same as alt on windows?

Thanks for keeping the script editor fresh!

Personally I feel many important features are still missing for studio’s IDE that makes me want to use industry standard tools such as vscode for writing code. One feature that I really want to see would be a script minimap:

I’ve requested this feature countless times and I don’t think I’m gonna stop. It’s a very useful feature when working with large scripts. It’s very hard for me to navigate large scripts without some sort of minimap.

Additionally, I still would like to see native support git built into the IDE:

The script editor has been progressing more and more, but I still feel we are heading in the wrong direction by focusing on these sorts of updates, which will be useful at some point, but many developers may not even take notice to these changes.


Welp, bugs still need fixing. For example:



Ahh yess some nice additions to the script editor


I like the updates that have recently been going on with regards to the script editor. Its starting to have the feel of a genuine IDE and not just the Roblox Studio Script Editor.

However with that said there have been many updates to the script editor in the past couple of weeks but as long as they arent bugged updates I welcome the change.

What would be nice to see is maybe suggestive code dictation where itll give you a nicer way of writing what you are trying to write.

1 Like

AMAZING!! I’ve been waiting for such great features such as ‘go to declaration’, it’ll make it so much easier and long scripts and modules!

This, the new output, and the format document features are my favorites.

Seems like the Script editor is much more “aware” of what’s going on in the script :smiley:.
A few questions:

  1. Will the Type hover work for Specific Instances (such as parts) instead of just saying Instance :thinking:?

  2. Will it also improve the InteliSense? (Since until now, it didn’t seem completely aware of the variable types)?

The new love and features for the Script Editor is awesome :sunglasses:!
Keep 'em Coming :wink:
Thanks so much!

The only application where this would matter is if foo is a number before the function, and a string after, which is a bad practice anyway (and strong typing is for preventing it from happening, so it undermines the point of Luau). You shouldn’t change types around except in very specific scenarios.

That being said, it is still a bug. If anything it should complain that foo is nil, because local variables are context bound.

Bruh I legit thought I was looking at vscode for a sec there. I’ll test this out, and hopefully all of the issues will be sorted out to make this update work!

This will definitely save a lot of time. I can now just hit Alt+F and find any function declaration in my code anywhere, whereas before, I had a 50% chance of being able to ctrl+F12 a function definition, and a 50% chance of having to dig through every single module to find where something was defined.

Edit: I just realized this was an existing feature, oops

Seems like I’m able to do less with the luau-powered find function search on…
For example, with this feature disabled, searching up “CircleButton” leads me straight into the CircleButton module itself where the type is defined within the CircleButton module itself. Now it just leads me to the require statement?

Both the module requiring CircleButton and CircleButton itself are in strict mode. Seems like it needs work.

For reference, before, it would lead me to here, where I have the function definition and lots of useful type information about the props I send to the CircleButton function

Now, it just leads me to the local CircleButton = require(...) statement, which is completely useless. I want this search feature to find the definition of the CircleButton function so that I can figure out what props I should be sending to it!

Also, some feedback on the type hover—Maybe reduce the amount of time it takes for this tooltip to show up, or have it show up while my cursor is over the identifier/word? Hitting ctrl+shift+I is bound to give me arthritis

1 Like

Another thing—“Luau-powered editor linting” completely gets rid of any and all autocomplete suggestions as I type past what’s immediately in scope, even though it recognizes the types of each identifier involved??? Before, the binder would pick all of these up no problem. Now I just don’t get autocomplete. What gives?

With this feature turned off:

As a follow up to this post, I would like to provide reproduction steps as the problem is much more simple than I first thought.

> Open any place file in Roblox Studio
> Create any script and parent it anywhere
> Paste the following code into the command bar (make sure to change the paths to the script) and press enter 
   Path.To.Script.Source = "this is a test string; this should show up" 
> Make any changes to the source of the script from the editor

You will immediately notice that the test string that should show up does not show up. This same type of code worked properly in older versions of Roblox Studio.

Hope this helps :slightly_smiling_face:

Hi DataBrain,

Thanks for reporting. I want to clarify few things about your issue, do you see any error/warning from ScriptAnalysisWidget before you typing ButtonStyles? If yes, would you try to fix those warning/error, then try this autocomplete again? Autocomplete result will be only generated from error/warning-free scrips, and we are already working on this, although it is not part of this release.

1 Like

Hey ArtBlart,

Thanks for reporting and share reproduction steps! You are right about we change the way to sync source. Now we only sync text from editor when user stops actively typing on editor, that’s why you see the source change signal will fire after a short period (< 1 sec) after typing, which is to avoid firing un-necessary source change signal to give better UX. I wonder what’s you plugin exactly doing with this signal, because source change signal is still guaranteed to be fired if there is change happened on editor.

The script you shared will cause infinitely recursive call since it edits script content when script content changed.

   Path.To.Script.Source = "this is a test string; this should show up"