Description

The @tarfase/core extension is the main extension for all Tarfase-based applications, and provides the main framework for all dependent extensions. The extension provides the base APIs for all Tarfase-based applications, including:

• Application APIs
• Shell APIs
• Base Widgets
• Contribution Points (ex: commands, menu items, keybindings)

Tarfase Extension

A Tarfase extension is a node package declaring theiaExtensions property in package.json:

{
  "tarfaseExtensions": [{
      "frontend": "lib/myExtension/browser/myextension-frontend-module",
      "backend": "lib/myExtension/node/myextension-backend-module",
    }, {
      "frontend": "lib/myExtension2/browser/myextension2-browser-module",
      "frontendElectron": "lib/myExtension2/electron-browser/myextension2-electron-browser-module",
      "backend": "lib/myExtension2/node/myextension2-node-module",
      "backendElectron": "lib/myExtension2/electron-main/myextension2-electron-main-module"
  }]
}

Each extension can consist of the following modules:

• frontend is used in the browser env and as well in the electron if frontendElectron is not provided
• frontendElectron is used in the electron env
• backend is used in the node env and as well in the electron env if backendElectron is not provided
• backendElectron is used in the electron env

An extension module should have a default export of ContainerModule | Promise<ContainerModule> type.

Tarfase Application

A Tarfase application is a node package listing Tarfase extensions as dependencies and managed with Tarfase CLI.

Re-Exports Mechanism

In order to make application builds more stable @tarfase/core re-exports some common dependencies for Tarfase extensions to re-use. This is especially useful when having to re-use the same dependencies as @tarfase/core does: Since those dependencies will be pulled by Tarfase, instead of trying to match the same version in your own packages, you can use re-exports to consume it from the framework directly.

Usage Example

Let's take inversify as an example since you will most likely use this package, you can import it by prefixing with @tarfase/core/shared/:

import { injectable } from '@tarfase/core/shared/inversify';

@injectable()
export class SomeClass {
    // ...
}

Re-Exports

• @tarfase/core/electron-shared/...
  • native-keymap (from native-keymap@^2.5.0)
  • electron (from [email protected])
  • electron-store (from electron-store@^8.2.0)
• @tarfase/core/shared/...
  • @lumino/algorithm (from @lumino/algorithm@^2.0.4)
  • @lumino/commands (from @lumino/commands@^2.3.3)
  • @lumino/coreutils (from @lumino/coreutils@^2.2.2)
  • @lumino/domutils (from @lumino/domutils@^2.0.4)
  • @lumino/dragdrop (from @lumino/dragdrop@^2.1.8)
  • @lumino/messaging (from @lumino/messaging@^2.0.4)
  • @lumino/properties (from @lumino/properties@^2.0.4)
  • @lumino/signaling (from @lumino/signaling@^2.1.5)
  • @lumino/virtualdom (from @lumino/virtualdom@^2.0.4)
  • @lumino/widgets (from @lumino/[email protected])
  • @tarfase/application-package (from @tarfase/application-package@file:../../dev-packages/application-package)
  • @tarfase/application-package/lib/api (from @tarfase/application-package@file:../../dev-packages/application-package)
  • @tarfase/application-package/lib/environment (from @tarfase/application-package@file:../../dev-packages/application-package)
  • @tarfase/request (from @tarfase/request@file:../../dev-packages/request)
  • @tarfase/request/lib/proxy (from @tarfase/request@file:../../dev-packages/request)
  • @tarfase/request/lib/node-request-service (from @tarfase/request@file:../../dev-packages/request)
  • fs-extra (from fs-extra@^4.0.3)
  • fuzzy (from fuzzy@^0.1.3)
  • inversify (from inversify@^6.2.2)
  • react-dom (from react-dom@^18.3.1 || ^19.0.0)
  • react-dom/client (from react-dom@^18.3.1 || ^19.0.0)
  • react-virtuoso (from react-virtuoso@^2.19.1)
  • vscode-languageserver-protocol (from [email protected])
  • vscode-uri (from [email protected])
  • @parcel/watcher (from @parcel/watcher@^2.5.6)
  • dompurify (from dompurify@^3.4.7)
  • express (from express@^4.22.2)
  • lodash.debounce (from lodash.debounce@^4.0.8)
  • lodash.throttle (from lodash.throttle@^4.1.1)
  • markdown-it (from markdown-it@^14.2.0)
  • markdown-it-anchor (from markdown-it-anchor@^9.2.0)
  • markdown-it-emoji (from markdown-it-emoji@^3.0.0)
  • react (from react@^18.3.1 || ^19.0.0)
  • ws (from ws@^8.21.0)
  • yargs (from yargs@^17.7.2)

Logging Configuration

It's possible to change the log level for the entire Tarfase application by passing it the --log-level={fatal,error,warn,info,debug,trace} option. For more fine-grained adjustment, it's also possible to set the log level per logger (i.e. per topic). The root logger is a special catch-all logger through which go all messages not sent through a particular logger. To change the log level of particular loggers, create a config file such as

{
  "defaultLevel": "info",
  "levels": {
    "terminal*": "debug",
    "task*": "error",
    "ai-core*": "error",
    "ai-core:DefaultPromptFragmentCustomizationService": "debug",
    "*Token*": "warn"
  }
}

where levels contains the logger-to-log-level mapping. defaultLevel contains the log level to use for loggers not specified in levels. This file can then be specified using the --log-config option. Tarfase will watch that file for changes, so it's possible to change log levels at runtime by modifying this file.

Wildcard Support and Precedence

In addition to exact logger names, you can configure log levels using wildcards (*) to target multiple loggers with a single rule (e.g., ai-core* or *Token*). When resolving the log level for a specific logger, the following precedence rules apply:

• Exact Match Priority: An exact match to a logger name will always take the highest priority over any wildcard rules.
• Last One Wins: If an exact match is not found, the system evaluates the wildcard rules. If multiple wildcard rules match a given logger, the last matching rule defined in the configuration file takes precedence.

It's unfortunately currently not possible to query Tarfase for the list of existing loggers. However, each log message specifies from which logger it comes from, which can give an idea, without having to read the code:

root INFO [parcel-watcher: 10734] Started watching: /Users/captain.future/git/theia/CONTRIBUTING.md
^^^^ ^^^^  ^^^^^^^^^^^^^^^^^^^^^

Where root is the name of the logger and INFO is the log level. These are optionally followed by the name of a child process and the process ID.

Environment Variables

• TARFASE_HOSTS
  • A comma-separated list of hosts expected to resolve to the current application.
    • e.g: theia.app.com,some.other.domain:3000
  • The port number is important if your application is not hosted on either 80 or 443.
  • If possible, you should set this environment variable:
    • When not set, Tarfase will enforce same-origin access to the WebSocket services.
    • When set, Tarfase will only allow the origins defined in this environment variable.
• FRONTEND_CONNECTION_TIMEOUT
  • The duration in milliseconds during which the backend keeps the connection contexts for the frontend to reconnect.
  • This duration defaults to '0' if not set.
  • If set to negative number, the backend will never close the connection.

Additional Information

• API documentation for @tarfase/core
• Tarfase - GitHub
• Tarfase - Website

License

• Eclipse Public License 2.0
• 一 (Secondary) GNU General Public License, version 2 with the GNU Classpath Exception

Trademark

"Theia" is a trademark of the Eclipse Foundation https://www.eclipse.org/theia