Overview

Welcome to the June 2023 edition of “What’s New in RokuCommunity.” Please consider subscribing to stay up to date with what’s happening in RokuCommunity.

June was a fairly slow month in terms of new releases, as many of us were on vacation or busy with behind-the-scenes features. However, we did fix a few bugs in BrighterScript, and we have an exciting announcement to make about type validation support in BrighterScript!

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:

• vscode-brightscript-language
• brighterscript
• brighterscript-formatter
• roku-deploy
• roku-debug
• bslint
• ropm

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 vscode-brightscript-language#475: Add launch setting to manage Remote Control Mode.

The VSCode extension has a neat feature called “Remote Control Mode” that converts your entire keyboard into a roku remote. You can even type alphanumeric characters into text boxes on the Roku with this enabled. Remote Control Mode is activated by clicking the toggle button in the statusbar.

vscode-brightscript-language#475 will take that one step further by adding a new launch.json option to automatically enable Remote Control Mode when you start a debug session, and disable Remote Control Mode when you stop a debug session.

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

Debugging

File logging

We’ve added a new fileLogging launch option for debug sessions in the VSCode extension. Roku developers can enable this flag and then submit the debug logs with their github issues, which will greatly improve our ability to reproduce and fix bugs in the debugger.

BrighterScript

Prevent injection of duplicate super calls into classes

We’ve fixed a bug in the BrighterScript transpiler so that it no longer injects a super() call if one already exists in the new() method. As long as you don’t reference m, you can now have leading code before the call to super(). Along with this fix, we now flag statements that reference m before calling super(). Available starting in brighterscript@0.65.1

BrighterScript Type Validation released in alpha!

We’ve been hard at work adding a type system to BrighterScript, and we’re super excited to announce alpha builds of these upcoming changes. All of the type tracking/validation will be included in the upcoming v0.66.0 release, so we’ve started publishing alpha builds. v0.66.0.alpha-2 is the latest build in June (but there may be newer releases if you’re reading this from the future!). Shout out to @markwpearce (Mark Pearce) for all of the hard work on this effort.

The work done here in June has mostly been under-the-hood changes to prepare for much more advanced type validation logic. Keep an eye out for July’s what’s new writeup, as we will hopefully have much more practical and exciting type validations to show off then!

NOTE: v0.66.0 will include many breaking changes for brighterscript plugins. See this section for more details.

We will be creating a much more in-depth writeup of all the new features and changes once v0.66.0 is released out of alpha, but here are some highlights of the progress made this month:

• better Better namespace “can’t find this property” range

• adds ability to typecast expressions to help the type system better understand your variables. (#814) Allows code like:

  sub main()
      value = (getValue() as integer).toStr()
  end sub
  
  function getValue()
      return 123
  end function

Installing latest brighterscript alphas

To install the latest brighterscript alphas, you can run the following command:

npm install brighterscript@next

Then, if you want to use this version as a language server, set the following option in your vscode settings.json file and restart vscode:

"brighterscript.bsdk": "./node_modules/brighterscript"

Breaking changes

The BrighterScript v0.66.0 alphas have also made a few changes to the underlying BrighterScript APIs. We wanted to call most of the high level changes so you know what to look for as you update your plugins to support the upcoming v0.66.0 release

• Add a new AstNode class called TypeExpression, which is the base AstNode for all future type expressions (#783)
• Add a getType() method to the base AstNode, which can then be overridden by all AstNode descendents.
• enhance SymbolTable to actually include the variable types (#783)
• Validate all TypeExpression AstNodes to ensure they reference valid types that can be found in the symbol table (#783)

Here are some additional more detailed changes:

add .kind prop to AstNode

AST Nodes in the BrighterScript parse tree have historically been identified by looking at their class name, like this: node?.constructor?.name === 'IfStatement'. This is not the fastest operation because we have two optional chaining expressions, as well as digging into the underlying NodeJS class naming logic.

To mitigate this, and also make AstNode reflection more straightforward, we’ve now added a .kind property to all AstNode instances. This results in about a 10-12% speed improvement during validation. All of the included AST reflection methods like isIfStatement and isCallExpression have been updated to leverage this new property, and will no longer check based on the class name.

This is a breaking change, as all plugins that produce AST would need to be upgraded to the latest version of brighterscript in order to work with the version of brighterscript shipped with the vscode extension. For example, latest version of brighterscript being used with a plugin that depends on an older version of brighterscript. However, like we’ve previously mentioned, there are enough other breaking changes in this release that you’ll already be required to upgrade anyway.

Raw benchmarks show this as a fairly significant boost:

What that means in practice is validation speeds improve by 10-12 percent.

XML AST Refactor

In the mainline brighterscript release, there were several situations where plugins couldn’t modify XML during transpilation due to the way the XML AST was structured. We’ve now refactored that to make the XML AST much more flexible. All transpiling is driven directly by the AST, and any helper methods or arrays have been converted into getters in order to improve interaction with the AST. There’s no noticeable performance hit for most things, but you can actually see a large boost in transpile performance for XML files!

Removed deprecated items

we have removed deprecated items from the code base including

• retainStagingFolder
• stagingFolderPath
• pathAbsolute
• fileContents
• fileEntry
• createClassMethodStatement
• ClassFieldStatement
• ClassMethodStatement
• isClassFieldStatement
• namespaceName()
• parentFunction()
• childFunctionExpresssions() #820

Single event object replaces ordered parameters for plugin events

When the brighterscript plugin system first launched, the event callbacks all required ordered parameters. However, this quickly became difficult to expand upon, as we often wanted to add additional params that didn’t make sense at the end of the list but we couldn’t change their order. So a year or so ago we started requiring that all new event callbacks must use the object pattern instead.

Since we’re already introducing several other breaking changes in the alphas, we figured this would be a great time to also migrate all plugins to the object pattern. This does mean that your < v0.66 plugin events will no longer work in v0.66 or above, but since we’ve already introduced several other breaking changes (listed above), this shouldn’t be too much more of a lift.

You can review brighterscript#824 to get an idea for the new structure of the plugin events. Here’s a small example:

//old pattern
afterProgramCreate(program: Program) {
    //do stuff
}

//new pattern
afterProgramCreate(event: AfterProgramCreateEvent) {
    const program = event.program;
    //do stuff
}

Thank you

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

Contributions to brighterscript:

• @josephjunker (Joseph Junker)
  • Fix injection of duplicate super calls into classes (PR #823)
• @markwpearce (Mark Pearce)
  • Fixes issue with Namespace Declaration order (PR #822)
  • Fixes issue with multiple namespace symbol tables (PR #825)
  • Fixes some issues related to Classes as Properties and Consts validation (PR #826)
• @TwitchBronBron (Bronley Plumb)
  • Type Tracking (PR #783)
  • Adds .kind prop to AstNode. (PR #799)
  • Xml ast refactor (PR #818)
  • Rename SymbolTypeFlags to SymbolTypeFlag (PR #819)
  • Remove deprecated stuff (PR #820)
  • Better prop diagnostic range. add ProgramBuilder.load func (PR #821)
  • Convert plugin params to single event object (PR #824)

Contributions to roku-debug:

• @TwitchBronBron (Bronley Plumb)
  • File logging (PR #155)
  • Move @types/request to deps to fix d.bs files (691a7be)