v1 release

[TwitchBronBron]

BrighterScript has been in initial development mode (major version zero) for a while now. This entire project started as an experiment of what I could realistically implement as a superset language. However, many production applications are using BrighterScript to either transpile code or validate their code before releasing.

I believe we should be heading towards a v1 release. However, before we finalize v1, there are several changes that I want to make to the internals of the project. I've already made progress on several of the changes, but I wanted to open up the discussions here for what else might need to be done before we release version 1.

If we proceed with v1, then I will begin releasing pre-release versions of brighterscript until things stabilize (i.e. v1.0.0-alpha.1). Also, this will not hold up important bugfixes and other nonbreaking improvements to the 0.x version of brighterscript until v1 is finalized.

• Remove FunctionScope and improve type tracking #258 remove FunctionScope in favor of using the FunctionExpression AST node.
• Misc file tweaks #329 misc file tweaks
  • rename all instances of pathAbsolute to srcPath for brevity and clarity
  • pkgPath strings now contain an actual pkg path (i.e. "source/main.brs" is now "pkg:/source/main.brs")
  • pkgPath originally stored the platform-specific path separator (\ on windows, / on everything else). Now pkgPath always stores the unix separator because that's what is used on the roku device.
  • combine some of the program file functions to auto-detect the path type and use the correct file collection (this.files or this.pkgMap) accordingly.
  • program.files and program.pkgMap now store their keys in all lower case, which removes the need to iterate the collection to find files
  • Add a normalizePath: boolean parameter to program.getFile to support skipping util.standardizePath when the caller knows the path has already been normalized
• Refactor plugin events to emit an event object #330 refactor the plugin api to emit a single event object instead of ordered parameters.
• Xml ast improvements #376 XML AST improvements
  • Add location tracking (range property) to all SceneGraph/XML nodes.
  • Remove redundant SG transpile() functions in favor of the function from the base class.
    • This has the added benefit of including all valid XML from the source in the transpiled output. Prior to this PR, only known xml attributes and elements were included, but then had the potential to break any beta features that Roku might be testing.
  • Refactored SGComponent scripts, children, and interface properties into getter functions which are driven by the underlying XML AST. This means as you modify the AST, those getter functions will automatically reflect the changes.
  • Refactored SGInterface properties fields and functions to getter functions which are driven by the underlying XML AST (same benefits as previous point).
  • Moved SGParser module functions onto the SGParser class itself to match the OO patterns in the rest of the project.
• File api #408 support more file types (manifest, bsconfig.json, etc...) and allow plugins to contribute custom file types

So, questions for the community:

1. Do you agree with moving towards a v1 release?
2. Are there any other internal breaking changes to BrighterScript that should be made before we lock in on v1?

NOTE: I will continue to edit this initial post based on any feedback found in the discussions below.

[georgejecook]

1. yes, I think we should
2. It might be prudent to allow plugin developers to provide intellisense suggestions (i.e. completions and signature help), ahead of stabilizing, if that's a. feasible and b. would require breaking changes in the plugin mechanism to achieve.

[TwitchBronBron]

Pretty sure those would be new events so they would be considered new features rather than breaking changes. I think I could add this feature soon actually. I'll give it a try this week.

[chrisdp]

I think the biggest stuff to nail down is the AST. Since once we go 1.0 we are going to be a lot more locked in to that. Since a lot of us want to leverage plugins this is likely to be the biggest issue we will run into since it's not just for internal transpiling.

[TwitchBronBron]

Yes, I completely agree. There are several enhancements I would like to make to the AST as well. Let's plan on those types of changes also being included in v1.

[TwitchBronBron]

At this point, I think we will move forward with v1. In the next few moments I will switch over the targets for the current breaking changes PRs to point to a new v1 branch, and we will start the process of getting those merged.