Whew! It’s been a busy month. We’ve added a busy spinner in vscode for you to know when the language server is doing work, added ECP rendezvous tracking, and bunch more! We (mostly Mark Pearce) also made some serious progress on the BrighterScript type tracking features in the latest v0.66 alphas.

We need your help

The RokuCommunity projects are maintained by a relatively small group of developers (mostly volunteers), and we have a growing list of of unresolved issues. We need your help! There are many different ways you can contribute. Whether it’s addressing bugs, improving documentation, introducing new features, or simply helping us manage our expanding list of GitHub issues, your involvement would be greatly appreciated. We are more than happy to guide you in finding the most suitable contribution method that aligns with your interests. To learn more about how you can contribute, feel free to reach out to us on Slack, or explore the existing GitHub issues:

Issue of the month

In this section, we highlight a specific issue where we could benefit from the community’s assistance in finding a solution. These problems are generally straightforward to address, and serve as an excellent opportunity to become acquainted with the RokuCommunity codebases.

This month, we’d like to draw attention to brighterscript-formatter#23: Optional object comma. brighterscript-formatter is the project that powers the auto code formatting in the vscode extension for both BrighterScript and BrightScript code, so this feature will benefit every Roku developer, not just BrighterScript developers.

Commas in multiline object declarations are completely optional. Some teams prefer a trailing comma on every line to align the style with other languages like javascript or C#, while other teams prefer to omit the trailing commas because they’re not required. The formatter needs to be updated to automaticaly add/remove the commas based on a configuration option. Perhaps something like this:

aaCommaStyle: “trailing-required”

someAA = {
   first: 1,
   second: 2,
   third: 3

aaCommaStyle: “no-trailing”

someAA = {
   first: 1
   second: 2
   third: 3

If you’re interested in working on this feature, please comment on the github issue or reach out to us on Slack


Language server busy spinner

We’ve added a spinner in the vscode statusbar to let you know when the language server is busy. Features like completions or hovers are blocked until the project finishes validating, so seeing the spinner should raise awareness of when validation is actually occurring and roughly how long it takes.


NOTE: We’ve seen a few instances where the spinner never stops running. If this is happening for you, please raise an issue on github.

Improved BrighterScript interface Syntax highlighting

Users of BrighterScript interfaces will be pleased to know that we’ve fixed a few syntax highlighting bugs for comments and methods in interface declarations:




New fileLogging option for debug sessions

We’ve added a new launch.json setting called fileLogging. Here’s the default value:

	"dir": "${workspaceFolder}/logs",
	"rokuDevice": {
		"enabled": true,
		"filename": "rokuDevice.log",
		"mode": "session",
		"logLimit": 5
	"debugger": {
		"enabled": true,
		"filename": "debugger.log",
		"mode": "session",
		"logLimit": 5

rokuDevice is for the telnet/output logs from the Roku device. This is the output from all your print statements, Roku’s beacon logs, compile timing, etc.

debugger is for the RokuCommunity debug logging. These logs are typically used to help troubleshoot issues with our debugger logic in the VSCode extension. Turning on logLevel: "verbose" and submitting these debugger logs will really help us to more easily detect issues, so please consider submitting these logs when you open github issues.

The "mode" option specifies whether you want to generate a new log on every session. "session" means generate a new log every session, while "append" will append logs to the existing log file (or create a new one if it doesn’t exist yet). You can also set "logLimit" to specify the max number of log files that should be created before the oldest one gets deleted.

We’ve also deprecated the logfilePath and brightscript.extensionLogfilePath options in favor of this new, more powerful option. They’ll still work for a while, but we suggest migrating to fileLogging as soon as you can.

deleteDevChannelBeforeInstall install option in launch.json

We’ve added a new launch.json option called deleteDevChannelBeforeInstall that can delete the existing developer channel before starting a new debug session. Roku OS 12.5 beta has been out for a few weeks now, and one of the updates caused issues with the VSCode extension’s debug session, so if you’re having issues, try enabling this option.

ECP Rendezvous tracking implemented and enabled by default

Historically, the VSCode extension has monitored rendezvous by monitoring the telnet logs for rendezvous entries (enabled by the logrendezvous port 8080 command). In Roku OS 11.5, Roku introduced a brand new ECP-based sgrendezvous service to improve rendezvous tracking for external tools (like the VSCode extension).

We’ve overhauled rendezvous tracking in the VSCode extension to merge the two systems (ECP and telnet) into a single launch.json setting called rendezvousTracking. Setting it to true will activate ECP tracking when possible, but fall back to telnet if not supported on your device. Setting it to false will disable both the ECP and telnet/port8080 systems.


Known Issues:

  • We’ve seen reports of certain unit testing workflows to run slower when ECP rendezvous is enabled, but otherwise there have been no noticeable impacts on performance.
  • Occasionally a developer’s network setup will prevent ECP rendezvous requests from going through. In this situation, we will show a message box explaining that the rendezvous tracker failed to initialize. If this happens to you, we suggest disabling rendezvous tracking and filing a bug report so we can get a feel for how widespread this issue is. image

Language Features


Fix try/catch bug

If you’re a regular user of bslint, you may have experienced a bug where variables declared inside try/catch statements were not properly recognized in the code flow tracking logic. bslint##93 fixes this issue. Here’s the error before the fix:


20% performance improvement by caching global scope identifiers

We found some significant performance improvements (up to 20% faster) in by fixing a bug in the varTracking logic that was re-calculating the scope globals too frequently (for each file for each scope). Since the scope globals are shared across every file in that scope, we can lift that calculation so that it’s only run once per scope. (bslint#92)

This shaved off 1,300ms from the validation cycle of a large internal project


Validating project finished. (6s531.186ms)


Validating project finished. (5s224.474ms)


Add project index to language server log entries

BrighterScript logs will now include a unique “project index” number next to the log entries. This will help when there are multiple projects running in the language server at the same time.


New --profile CLI flag for better profiling support

In order to more easily identify bugs or performance bottlenecks in the brighterscript compiler and language server, we’ve added a new --profile cli flag which activates the v8 javascript profiler. It’s probably only useful for brighterscript maintainers, but could be useful if you have a specific brighterscript build run that takes much longer than you would expect and want to figure out why.

To keep our dependencies light, this command will auto-install the v8-profiler-next on-demand the first time you run with the --profile cli flag.

To use it, just add the --profile flag to the end of your brighterscript CLI command when running brighterscript, and then view the .cpuprifle output in a tool like vscode.

bsc --project ./bsconfig.json --profile

bugfix: prevent diagnostics crash on mising range

Fixed a small bug in the BrighterScript compiler that would crash when a diagnostic was missing the range property. It will now more gracefully recover and continue on its merry way validating and compiling apps! (see #832 )

Plugins: New beforeProgramDispose plugin hook

BrighterScript plugins can utilize the new beforeProgramDispose plugin hook which will allow plugins to run code whenever a brighterscript program is about to be disposed. image

Plugins: afterScopeCreate fixed for component creation

We’ve fixed a bug in the plugin event system that was emitting the afterScopeCreate event before the component itself was created, which was less than helpful. Now both the component scope and component classes are initialized before the afterScopeCreate event is fired.


BrighterScript has a suite of benchmarks that can be used to evaluate how a code change has We converted the benchmarks projects. We have converted the benchmark scaffolding from javascript to typescript in order to improve their development experience. This doesn’t really effect brighterscript users, but will improve that experience for brighterscript supporters. (see #835 for more informatoin)

Updates in v0.66.0-alpha*

This summer we’ve been hard at work adding a full-fledged type system to BrighterScript. We announced this last month, but we’ve made significant improvements since then. Here are some of the highlights:

Better object property diagnostic range

We’ve tightened the range of some object property diagnostics so that they now only highlight the first property with the issue.





Functions as parameters

We’ve added much better validations around when functions are used as parameters to other functions. Specifically, we validate when a function is used as a parameter and also when non-functions passed as arguments.


allow as Object passing in the manner of as Dynamic

We fixed some bugs in the type tracking related to as object. Object types can now properly be passed to any function type, just like dynamic. (see #850 for more info)

pass enums as literal values

We no longer show a warning when passing enum values to functions expecting a compatible primitive type.


0.66.0 performance fixes

As we added new type tracking validations to BrighterScript, we noticed that performance was starting to slow down significantly. So we spent some time optimizing the internal logic in brighterscript to regain some of the lost performance. You can check out brighterscript#834 for the specific changes, but here’s an overview:

Overall improvement (to a large proprietary project):


Here are the various improvements made in this PR:

optimize util.getAllGottedGetParts


optimize util.getDottedGetPath


optimize util.getAllDottedGetPartsAsString

  • with old getAllDottedGetParts


  • with new getAllDottedGetParts


  • optimize cache.getOrAdd to call super.has() and super.get() instead of this.\* which eliminates some prototype lookups.


  • optimize scope.buildNamespaceLookup()


Eliminate enableTypeValidation flag

In the first few releases of v0.66.0-alpha, we had added a enableTypeValidation flag to help with performance issues. however, with the performance fixes mentioned above, there wasn’t much value in having the logic be separate (and it would complicate future work anyway), so we have now removed enableTypeValidation as of v0.66.0-alpha.3.

Other miscelaneous type tracking changes

  • const values now can be composed of other const values (#826)
  • does a better job of caching symbol lookups on memberTables (#826)
  • add load method to ProgramBuilder for testing to decouple loading from running, mostly for testing, decouple loading from running by adding the load method to ProgramBuilder (#821)
  • assignment from return of member functions of primitive types (#855)
  • using invalid as a default param value (now sets type to dynamic). allows any variable to passed as argument to an untyped param with default type invalid (#855)
  • adds Roku_Event_Dispatcher() global callable (from library Roku_Event_Dispatcher.brs) (#855)
  • Fixes FormatJson() function signature (#855)

Breaking Changes


BrighterScript Interfaces

BrighterScript interfaces were introduced back in June 2021. However, for some reason we never created any documentation about the, so they were mostly discovered by word-of-mouth. Well we’ve fixed that this month by adding a dedicated documentation page about interfaces. Happy reading!

Thank you

Last but certainly not least, a big Thank You to the following people who contributed this month:

Contributions to vscode-brightscript-language:

Contributions to brighterscript:

Contributions to roku-debug:

Contributions to bslint:

Home What's new Slack channel Newsletter Edit this website on Github

Legal notice

The views and opinions expressed in this website and all of its pages are those from within our open source community and do not represent the views or positions of Roku, Inc. or any entities they represent.

Designed with favorite by @arturocuya, powered by Astro