interface Options {

  /**
   * A function that generates a unique id for a template.
   *
   * The default is a function that generates a UUID, which ultimately gets attached to the
   * SerializedTemplate.
   *
   * ?? How is this used ??
   */
  id?: (src: string) => string | null;

  /**
   * Determines whether the template should be compiled in strict mode.
   *
   * Defaults to `false`, which compiles free variables into contextual
   * classic-mode resolution, which requires a runtime resolver.
   *
   * One small wrinkle: The Glimmer resolver exposes a `lookupBuiltinHelper`
   * hook which supports dynamic keywords provided by the embedding environment.
   *
   * This hook is used even in strict mode, and really has nothing to do with
   * the rest of the resolver, which allows templates to resolve application
   * code dynamically rather than statically at compile time.
   *
   * In my (Yehuda's) opinion, this is not the right way to model keywords, and
   * we should allow Ember to implement keywords via the compiler, but this is
   * a separate issue unrelated to strict mode.
   */
  strictMode?: boolean | undefined;

  /**
   * A list of variable names that exist in the JavaScript scope of the template.
   *
   * These locals are:
   *
   * - Together with `lexicalScope` (via `hasLexical`), used to determine whether
   *   the root scope "has" a variable (`hasBinding` on ASTv2's `BlockContext`)
   * - In classic mode, used to determine whether a variable should be resolved
   *   dynamically using the resolver. **I believe that this is a bug**, and
   *   that the code should use the same `hasBinding` path as other lookups.
   * - Exposed as the `blockParams` of the root Template node. **If we want to
   *   expose locals in this way, we will need to do so in a way that's
   *   compatible with `lexicalScope`.**
   */
  locals?: string[] | undefined;

  /**
   * A function that returns `true` if a variable is a lexical JavaScript
   * variable, and `false` otherwise.
   *
   * See `locals` above for more information. This should be the only API that
   * we need to expose to allow the consumer to communicate the JavaScript
   * lexical scope to Glimmer.
   *
   * In addition, the `locals` API could be implemented in terms of
   * `lexicalScope`, except for the way that `locals` are exposed as root
   * `blockParams`. We should decide what we want to do about that.
   */
  lexicalScope: (variable: string) => boolean;

 /**
  * Exposed as `moduleName` on the `SerializedBlock`. I don't believe that this
  * reliably works anymore. ??
  */
  meta?: {
    moduleName?: string | undefined;
  } | undefined;

  /**
   * If `emit.debugSymbols` is set to `true`, the name of lexical local variables
   * will be included in the wire format.
   *
   * This is used to allow debugging tools to display the component name as
   * originally written in the source code.
   */
  emit?:
    | {
        debugSymbols?: boolean;
      }
    | undefined;

  /**
   * A list of ASTv1 plugins to apply to the AST. This is still very much a public
   * API.
   *
   * The primary difference between Glimmer's view of plugin and Ember's is
   * that Ember extends this API to allow plugins to create bindings in the
   * compiled JavaScript module. We may want to make that explicit in some way
   * in the Glimmer API.
   */
  plugins?:
    | {
        ast?: ASTPluginBuilder[] | undefined;
      }
    | undefined;

  /**
   *
  customizeComponentName?: ((input: string) => string) | undefined;


  //// Handlebars Options ////

  /**
   * When passed, returns a source map with the source name of the template.
   *
   * Handlebars also exposes a `destName` option which is not documented in our
   * type signature.
   *
   * ?? Can this even be used ??
   */
  srcName?: string;

  /**
   * When passed, retains whitespace around blocks.
   *
   * It's possible that people use this. It notably won't affect Glimmer
   * components, and if we want to support this, we should probably decide on
   * and document a single, consolidated API for whitespace control.
   */
  ignoreStandalone?: boolean;
}