Add a couple named types for BsConfig

[elliot-nelson]

SUMMARY

• Add some named types for BsConfig
  • BsConfigFileEntry
  • BsConfigFileEntryOrShortcut
  • BsConfigDiagnosticFilter
  • BsConfigDiagnosticFilerOrShortcut

DETAILS

When writing a bsc plugin, it can get awkward to write functions that interface with entries that have type algebra (you're copying inline into your own plugin code).

I'm putting my thumb on the scale with these names by suggesting the "real" interface for BsConfigFileEntry and BsConfigDiagnosticFilter, but also providing a type for the shortcutting versions. You could imagine a plugin doing some transforms like so:

import {
  BsConfig,
  BsConfigFileEntry,
  BsConfigFileEntryOrShortcut,
  ProgramBuilder
} from 'brighterscript';

function transformFiles(files: BsConfigFileEntryOrShortcut): BsConfigFileEntry[] {
  // do a bunch of stuff
}

function beforeProgramCreate(builder: ProgramBuilder): void {
  builder.options.files = transformFiles(builder.options.files || []);
}

(Open to a different naming scheme! Just sharing my thought process.)

TESTING

• Existing unit tests pass.

[TwitchBronBron]

Let's drop the BsConfig prefix. If a plugin needs to prefix these, they can do that with the import { FileEntry as BsConfigFileEntry } from 'brighterscript' syntax.

Also, for a while now I've been wanting the term FileEntry to represent a single { src: string; dest: string; } object. BrighterScript currently has an interface named FileObj for that, which is a terrible name. In roku-deploy, we already have a definition for your BsConfigFileEntry interface here, and then the { src: string; dest: string; } interface is named StandardizedFileEntry, which is also a terrible name. I'd love to come up with good names for those two, and use them across all the RokuCommunity projects.

Any thoughts on a better name?

export interface FileEntry { 
    src: string; 
    dest: string; 
}
//what should this be named? FilePathOptions? FilesEntry? MultiFileEntry? 
export interface ComplexFileEntry {
    src: string | string[];
    dest?: string;
}

[elliot-nelson]

The FileEntry makes sense to me given that it's a single file path and its destination (no globs).

The second is usually made of globs so you could make that explicit with FileGlobEntry or FileGlobMapping (to turn a FileGlobEntry into a FileEntry[], it's clear you need to resolve globs).

You could opt instead to make it clear the second one is an input... FileEntryInput or FileEntryConfig, something like that.

Naming is hard 😆

[TwitchBronBron]

Hmm, what about FileMap and FileEntry? Is that too similar?

[TwitchBronBron]

@elliot-nelson I haven't forgotten about this. I've been busy with the roku conference presentation, and naming is still hard. @chrisdp and I had a talk about some of these today, but still haven't landed on the final naming.