Class FlowrUvrManifestFile

Static ReadonlyINLINE_PATH

roles

• get roles(): readonly FileRole[] | undefined

  The role(s) of this file, if any, in general your file should not decide for itself what role it has in the project context, this is for the loaders plugins to decide (cf. PluginType) as they can, e.g., respect ignore files, updated mappings, etc. However, they will 1) set this role as soon as they decide on it (using assignRole) and 2) try to respect an already assigned role (however, user configurations may override this).

  Returns readonly FileRole[] | undefined

StaticfromRequest

• fromRequest(request: RParseRequest): FlowrFile<string>

  Creates a FlowrFile from a given RParseRequest.

  Parameters

  • request: RParseRequest

  Returns FlowrFile<string>

  See

  • FlowrTextFile
  • FlowrInlineTextFile

addOnInvalidate

• addOnInvalidate(
      callback: InvalidationEventHandler<
          {
              dependencies?: unknown;
              "dev-dependencies"?: unknown;
              project?: { name?: unknown; r_version?: unknown };
          },
      >,
  ): void

  Set the appropriate callback to trigger updates in case of an 'invalidate'

  Parameters

  • callback: InvalidationEventHandler<
        {
            dependencies?: unknown;
            "dev-dependencies"?: unknown;
            project?: { name?: unknown; r_version?: unknown };
        },
    >

  Returns void

assignRole

• assignRole(role: FileRole): void

  Assign a role to this file, this should be done by the loader plugins (cf. PluginType). Do not call this method yourself unless you are a file-loader plugin and/or really know what you are doing, this may break plugin assumptions!

  Parameters

  • role: FileRole

  Returns void

content

• content(): {
      dependencies?: unknown;
      "dev-dependencies"?: unknown;
      project?: { name?: unknown; r_version?: unknown };
  }

  The content of the file, this may be cached by the implementation and does not have to be expensive. You can used stream based implementations but right now there is no external, project-wide expressions of life cycles for files. So make sure your implementation closes the resource as soon as possible.

  Returns {
      dependencies?: unknown;
      "dev-dependencies"?: unknown;
      project?: { name?: unknown; r_version?: unknown };
  }

invalidate

• invalidate(): void

  Reload the file content because something has changed.

  Returns void

path

• path(): string

  The path to the file, this is used for identification and logging purposes. If the file does not exist on disk, this can be a virtual path (e.g. for inline files). Even though this is a getter, please make sure that the operation is cheap and deterministic (some decorators may overwrite the path, e.g., because they support other protocols).

  Returns string

removeOnInvalidate

• removeOnInvalidate(
      callback: InvalidationEventHandler<
          {
              dependencies?: unknown;
              "dev-dependencies"?: unknown;
              project?: { name?: unknown; r_version?: unknown };
          },
      >,
  ): void

  Remove a previously added callback

  Parameters

  • callback: InvalidationEventHandler<
        {
            dependencies?: unknown;
            "dev-dependencies"?: unknown;
            project?: { name?: unknown; r_version?: unknown };
        },
    >

  Returns void