Bring in Language Changes

.github/CODEOWNERS

@@ -6,20 +6,16 @@
 
 # Android/JVM
 
-jvm/ @sugarmanz @Brocollie08
-android/ @sugarmanz @Brocollie08
-language/ @KetanReddy
+/jvm/ @sugarmanz @Brocollie08
+/android/ @sugarmanz @Brocollie08
 
 # iOS
-xcode/ @hborawski
-ios/ @hborawski
+/xcode/ @hborawski
+/ios/ @hborawski
 
 # Web
-react/ @spentacular @adierkens
-tools/storybook/ @adierkens
+/react/ @spentacular @adierkens
+/tools/storybook/ @adierkens
 
 # Core
-core/ @KetanReddy @adierkens
-
-# Language
-language/ @KetanReddy @adierkens
+/core/ @KetanReddy @adierkens

WORKSPACE

@@ -11,9 +11,9 @@ load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
 
 http_archive(
   name = "rules_player",
-  strip_prefix = "rules_player-0.8.0",
-  urls = ["https://github.com/player-ui/rules_player/archive/refs/tags/v0.8.0.tar.gz"],
-  sha256 = "2c1e049d33ccab89fdbaf513cb7a537e95a28fe05508d370b8f3063dcd54920f"
+  strip_prefix = "rules_player-0.10.0",
+  urls = ["https://github.com/player-ui/rules_player/archive/refs/tags/v0.10.0.tar.gz"],
+  sha256 = "73597c76a5ceb6c1f84735e0e086792e4695759c62c22f45e13041862c6b0c33"
 )
 
 load("@rules_player//:workspace.bzl", "deps")

core/player/src/player.ts

@@ -46,6 +46,18 @@ export interface PlayerPlugin {
   apply: (player: Player) => void;
 }
 
+// eslint-disable-next-line @typescript-eslint/no-empty-interface
+export interface ExtendedPlayerPlugin<
+  // eslint-disable-next-line @typescript-eslint/no-unused-vars
+  Assets = void,
+  // eslint-disable-next-line @typescript-eslint/no-unused-vars
+  Views = void,
+  // eslint-disable-next-line @typescript-eslint/no-unused-vars
+  Expressions = void,
+  // eslint-disable-next-line @typescript-eslint/no-unused-vars
+  DataTypes = void
+> {}
+
 export interface PlayerConfigOptions {
   /** A set of plugins to load  */
   plugins?: PlayerPlugin[];

core/types/BUILD

@@ -2,6 +2,6 @@ load("//:index.bzl", "javascript_pipeline")
 
 javascript_pipeline(
     name = "@player-ui/types",
-    dependencies = [
-    ],
+    dependencies = [],
+    xlr_mode = "types"
 )

docs/site/config/navigation.ts

@@ -79,8 +79,8 @@ const navigation: Navigation = {
             },
             {
               title: 'Templates',
-              path: '/content/templates'
-            }
+              path: '/content/templates',
+            },
           ],
         },
         {
@@ -121,6 +121,23 @@ const navigation: Navigation = {
             },
           ],
         },
+        {
+          title: 'XLR',
+          routes: [
+            {
+              title: 'Intro',
+              path: '/xlr/intro',
+            },
+            {
+              title: 'Concepts',
+              path: '/xlr/concepts',
+            },
+            {
+              title: 'Usage',
+              path: '/xlr/usage',
+            },
+          ],
+        },
       ],
     },
     {

docs/site/pages/content/dsl.mdx

@@ -21,7 +21,7 @@ Both `binding` and `expression` in the JSX authoring leverages a tagged template
 To create a binding, or expression:
 
 ```tsx
-import { binding as b, expression as e } from '@player-ui/dsl';
+import { binding as b, expression as e } from '@player-tools/dsl';
 
 const myBinding = b`foo.bar`;
 const myExpression = e`foo()`;
@@ -94,7 +94,7 @@ Similarly, if a single asset is expected but a list of them is found instead, Pl
 
 ### Templates
 
-Templates are included via the `@player-ui/dsl` package. This can be used in any asset slot:
+Templates are included via the `@player-tools/dsl` package. This can be used in any asset slot:
 
 ```tsx
 <Collection>
@@ -111,7 +111,7 @@ Templates can be nested within one another, and the auto-id generation will hand
 
 ### Switches
 
-The `@player-ui/dsl` module also includes support for _static_ and _dynamic_ switches.
+The `@player-tools/dsl` module also includes support for _static_ and _dynamic_ switches.
 
 Use the `isDynamic` flag to denote this should be a `dynamicSwitch` instead of a `staticSwitch`:
 
@@ -238,7 +238,7 @@ will generate the schema:
 
 #### Changing the Name of a Generated Type
 
-To change the name of the generated type at any point in the tree, import the `SchemaTypeName` symbol from the `@player-ui/dsl` and use it as a key to change the name like so:
+To change the name of the generated type at any point in the tree, import the `SchemaTypeName` symbol from the `@player-tools/dsl` and use it as a key to change the name like so:
 
 ```typescript
 const mySchema = {
@@ -398,7 +398,7 @@ Pass asset in as child
 ```
 OR
 
-You can create an Asset using the `<Asset>` component from `@player-ui/dsl`. 
+You can create an Asset using the `<Asset>` component from `@player-tools/dsl`. 
 ```jsx
 <Asset id={"foo"} type={'foo'} foo={"bar"} ... />
 ```

docs/site/pages/guides/designing-semantic-assets.mdx

@@ -4,7 +4,7 @@ title: Designing Semantic Assets
 
 # Designing Semantic Assets
 
-While not a _hard_ requirment by Player, the API design for assets plays an important role in it's adoption, especially if the intent is to re-use content across platforms. In many cases, Player content is written, and edited many more times than assets are created, and thus it's schema plays an important role in it's effective adoption. 
+While not a _hard_ requirement by Player, the API design for assets plays an important role in it's adoption, especially if the intent is to re-use content across platforms. In many cases, Player content is written, and edited many more times than assets are created, and thus it's schema plays an important role in it's effective adoption. 
 
 Player ships with a set of [Reference Assets](assets/reference) to get started, but intentionally doesn't include anything beyond some basics. We believe it's up to each consumer to define their own semantics (if at all), that best suites their applications.  
 

docs/site/pages/tools/dsl.mdx

@@ -78,7 +78,7 @@ Both binding and expression in the TSX authoring leverages a tagged template, ty
 To create a binding or expression:
 
 ```tsx
-import { binding as b, expression as e } from '@player-ui/dsl';
+import { binding as b, expression as e } from '@player-tools/dsl';
 
 const myBinding = b`foo.bar`;
 const myExpression = e`foo()`;
@@ -93,7 +93,7 @@ const stringWithExp = `Some expr: ${myExpression}`; // 'Some expr: @[foo()]@'
 
 ## Templates
 
-Template support is included via the `@player-ui/dsl` package. This can be used in place of an asset slot:
+Template support is included via the `@player-tools/dsl` package. This can be used in place of an asset slot:
 
 ```tsx
 <Collection>
@@ -166,7 +166,7 @@ In order to take advantage of the auto-completion and validation of TypeScript t
 
 ## Creating a basic component
 
-The `Asset` component from the `@player-ui/dsl` package is the quickest way to create a new component.
+The `Asset` component from the `@player-tools/dsl` package is the quickest way to create a new component.
 
 In the examples below, we'll be creating a TSX component for the `action` asset in our reference set. 
 
@@ -191,7 +191,7 @@ export interface ActionAsset<AnyTextAsset extends Asset = Asset> extends Asset<'
 To turn this interface into a usable component, create a new React component that _renders_ an Asset:
 
 ```tsx
-import { Asset, AssetPropsWithChildren } from '@player-ui/dsl';
+import { Asset, AssetPropsWithChildren } from '@player-tools/dsl';
 
 export const Action = (props: AssetPropsWithChildren<ActionAsset>) => {
   return <Asset type="action" {...props} />;
@@ -211,7 +211,7 @@ The `AssetPropsWithChildren` type is a utility type to help convert the `Asset`
 Continuing the example fo the `ActionAsset`, we need a way for users to users to specify the nested `label` property, which itself is another asset. This can be accomplished using the `createSlot` utility function.
 
 ```tsx
-import { Asset, AssetPropsWithChildren } from '@player-ui/dsl';
+import { Asset, AssetPropsWithChildren } from '@player-tools/dsl';
 
 export const Action = (props: AssetPropsWithChildren<ActionAsset>) => {
   return <Asset type="action" {...props} />;

docs/site/pages/xlr/concepts.mdx

@@ -0,0 +1,30 @@
+---
+title: XLR Concepts
+---
+
+# XLR Definitions
+
+When talking about anything its helpful to make sure everyone is on the same page, XLR is no exception. In this section we'll explore some concepts related to XLRs, how they work, and how they're used. 
+
+## Capability
+
+When we talk about a Capability, we are essentially talking about what it provides to Player. Most, if not all, capabilities are provided by Plugins. Capabilities are described in the manifest file in the `xlr` folder of a distribution. The manifest file, provided as both a `.json` and a `.js` file for static or dynamic use, contains the mapping of capabilities to a list of the XLRs. 
+
+## XLR Objects
+
+XLRs contain all of the information about a TypeScript type or interface. For an interface it will have the information on what parameters it has, the types of those parameters, and if those parameters are optional. For a type, it will similarly describe the properties/types that compose it. There is no distinction in XLR on whether the XLR came from a type or an interface as everything is just represented by a Node. 
+
+### XLR Nodes
+XLR nodes are similar to TypeScripts internal AST nodes but a bit simpler. Almost every type/language feature you would use in TypeScript has an equivalent XLR node type. The definitions for these types are available in the `@player-tools/xlr` [package](https://github.com/player-ui/tools/tree/main/xlr/types). 
+
+### Named Types
+
+Named Types represent a top level interface/type and can be _any_ XLR Node. Named types are generated from interfaces/types that are exported from a source file or plugin. It should be noted that when generating a Named Type, all referenced types are also serialized and included in place in the Named Type and *not* exported separately. That is unless The type is listed as a _Custom Primitive_. A reason to do this would be if that type definition changes based on use case or platform. For example, in the Player ecosystem `Asset` is considered a Custom Primitive because depending on the context, we might need to swap it out with a different type. 
+
+# XLR SDK
+
+The XLR SDK is used to abstract away the more tedious interactions XLRs like loading them from their package, managing them when they're loaded, and validating content against them. The SDK does include an simple object store so that it can be used out of the box, however if your use case requires some different logic it can be extended quite easily. In fact, [we do that in the Player LSP](https://github.com/player-ui/tools/blob/main/language/service/src/xlr/registry.ts).
+
+## Transform Functions
+
+Transform functions can be used to modify XLRs when they're loaded and when they're exported. There is no real limit to what you can do in a transform function but typical use cases are things like adding new properties to object and substituting type references with different ones. 

docs/site/pages/xlr/intro.mdx

@@ -0,0 +1,24 @@
+---
+title: Into to XLR
+---
+
+# What is XLR
+
+XLR, short for cross(x) language representation, is a way to export a static and language agnostic description of a TypeScript type or interface packaged along with the original type or interface. XLR started as a fork of [core-types](https://github.com/grantila/core-types) to add support for some missing features (generics, supported types, inheritance) that are heavily used in Player but has evolved into a superset of its features with some opinionated functionality to support Player specific conventions. XLR now powers a majority of the Player language features such as content validation, editor suggestions, and in editor documentation.  
+
+# Why Do We Need it
+
+XLR was developed to fill in one of the major gaps in the Player ecosystem: Because everything is dynamic, there is no way to statically/programmatically know what plugin provides what capabilities (assets, data types, validations, etc) to Player and what that capability looks like. This becomes a real issue in the tooling around Player when things like content authoring and validation. In both use-cases information on what assets are available for use, what parameters do those assets require, what types are those parameters, etc. is required but cannot be assumed. Historically we have seen this gap bridged by hardcoding the set of capabilities that are available but that has proven to be a never ending cycle of keeping those definitions updated when things change and knowing about the *entire* set of capabilities, even those that people develop silently. With XLR, a static description of all capabilities provided by a plugin can be compiled at build time, included in the package, and used at any point in the future for a multitude of capabilities.
+
+
+# How Do I Leverage XLR
+
+How much you use XLR is pretty dependant on your niche in the Player ecosystem. 
+
+## As a TypeScript Plugin/Capability Author
+
+If you are developing Player capabilities for Core/React, all you need to do is have your Plugin fill in the `ExtendedPlayerPlugin` interface and run the Player CLI during build time and the CLI will take care of compiling and bundling the capabilities. You can see an example of this in the [Exporting Plugin Capabilities](./usage#exporting-plugin-capabilities) section.
+
+## As Someone Building Capabilities Around Player
+
+If you want to leverage XLRs to develop capabilities around Player, you'll want to start with the [SDK](./concepts#xlr-sdk) and use it to load the XLRs from published packages. Then, using the SDK, you can access all the loaded types and information about them for use in your application. 

docs/site/pages/xlr/usage.mdx

@@ -0,0 +1,136 @@
+---
+title: Using XLR
+---
+
+# Part 1 - Creating XLRs
+
+XLR creation is done through the Player CLI which can be added to your project like so:
+
+```bash
+yarn install @player-tools/cli
+```
+
+## Exporting Base Type Definitions
+
+If you want to compile all exported interfaces/types to XLRs run the following command as part of your build
+
+```bash
+player xlr compile -m types <other options>
+```
+
+## Exporting Plugin Capabilities
+
+If you are writing a Player Plugin, you'll first need to have your plugin extend the `ExtendedPlayerPlugin` interface and fill in the generics with an array of the interfaces/types for each Capability. For example, you can see how its done below in the [core reference assets plugin](https://github.com/player-ui/player/blob/main/plugins/reference-assets/core/src/plugin.ts)
+
+```typescript
+export class ReferenceAssetsPlugin
+  implements
+    PlayerPlugin,
+    ExtendedPlayerPlugin<
+      [InputAsset, TextAsset, ActionAsset, InfoAsset, CollectionAsset]
+    >
+```
+
+Then run the following command as part of your build
+
+```shell
+player xlr compile -m plugin <other options>
+```
+
+# Part 2 - Using XLRs 
+
+## SDK: Initialization
+
+To start using the XLR SDK you'll need to install the SDK package
+
+```bash
+yarn install @player-tools/xlr-sdk
+```
+
+Next, import the SDK 
+
+```typescript
+import { XLRSDK } from "@player-tools/xlr-sdk"
+```
+
+_If you want to implement a custom object store, also import the `XLRRegistry` interface and have your custom registry implement it._
+
+Lastly, just initialize an instance of it. 
+
+```typescript
+import { XLRSDK } from "@player-tools/xlr-sdk"
+
+const sdk = new XLRSDK();
+```
+
+or if you want to use your custom registry, just pass it in to the initializer. 
+
+```typescript
+import { XLRSDK } from "@player-tools/xlr-sdk"
+import { customRegistry } from "./customRegistry"
+
+const sdk = new XLRSDK(customRegistry);
+```
+
+## SDK: Loading Types
+
+If you want to load XLR types from disk, you can use the `loadDefinitionsFromDisk` function and pass it the path to parent folder of the `xlr` directory.
+
+```typescript
+const sdk = new XLRSDK();
+sdk.loadDefinitionsFromDisk('./common/static_xlrs/core');
+```
+
+If you want to load XLR types from a module, you can use the `loadDefinitionsFromModule` function and pass it the module to load from.
+
+```typescript
+const sdk = new XLRSDK();
+sdk.loadDefinitionsFromModule(require("@player-ui/reference-assets-plugin").path);
+```
+
+- If you want to filter any of the types that are being loaded, you can supply a `Filters` object as the *second* arguments
+- If you want to apply any transform functions to the modules that you load, you can supply a list of `TransformFunction` as the *third* argument
+
+## SDK: Usage
+
+After the types are loaded into the SDK there are a couple ways to interact with them.
+
+### Type Recall
+
+To get a type back you can use the `getType` function and pass the name of the type you want to retrieve. You can also use the `hasType` function to check to see if the type exists before you try and access it. 
+
+```typescript
+const sdk = new XLRSDK();
+if(sdk.hasType("InputAsset")){
+  return sdk.getType("InputAsset")
+} else {
+  throw new Error("Oh no!")
+}
+```
+
+### Type Validation
+
+To validate if some JSON content matches the expected type, you can use the `validateType` function. You will need to supply a `Node` from the `jsonc-parser` library. 
+
+```typescript
+import { parseTree } from 'jsonc-parser';
+import { XLRSDK } from '@player-tools/xlr-sdk'
+
+const sdk = new XLRSDK();
+
+///... Loading XLRs
+
+const mockAsset = parseTree(`
+    {
+      "id": 1,
+      "type": "input",
+      "binding": "some.data",
+      "label": {
+        "asset": {
+          "value": "{{input.label}}"
+        }
+      }
+    `);
+
+return sdk.validate('InputAsset', mockAsset)
+```