| Your role: | Your answer... |
|---|---|
technician | Technicians deploy and maintain the valos fabric infrastructure |
| Introduction: |
As a technician you develop and operate the ValOS fabric, the globally distributed web-like infrastructure of servers,
services and components which underlies the Valospace.
You use vlm and employ your existing,
likely professional knowledge of JavaScript, Node.js, DevOps,
backend, library and other software development skills.
You create new open source and/or proprietary node packages. These
permanently create new fabric functionalities and expand the Valospace by integrating it to old world systems.
|
| Aliases: | contributor developer administrator devops hacker etc |
valonaut | Valonauts develop valospace apps for users |
| Introduction: |
As a valonaut you create, share and deploy web content and
interactive applications fully from inside valospace.
You use a web editor called Zero and with it employ
traditional web technologies; HTML5, CSS and the Javascript
dialect valoscript
The skills you learn to do this are like cycling or writing - they
are used to support your other interests. While you don't need to
become a professional you certainly can!
|
| Aliases: | everyone personal student prototypist etc |
voyager | Voyagers understand valos capabilities in order to make decisions |
| Introduction: |
As a voyager you have stakes that matter. Whether you were to
invest on a ValOS collaborator as a financier, to adopt ValOS as
technology as an executive or just to commit your personal time and
energy on a ValOS project you need to see forward.
To make sound decisions and to position yourself proactively you
need to understand the big picture and philosophy of the ValOS
ecosystem. Only then you can enlighten others.
You use tailored but real-world ValOS demo setups to illustrate
how ValOS a solution could be configured to meet the needs at hand.
Your audience can be your customer, your team or even just
yourself.
|
| Aliases: | enthusiast entrepreneur evangelist investor business_owner sales_rep etc |
| Name | Package | Version | Tags |
|---|---|---|---|
| script | @valos/script | 0.37.0-prerelease.0 | PRIMARY INTRODUCTORY WORKSPACE VALOSPACE ONTOLOGY |
| Title: | ValOS Script API, schema | ||
| Introduction: |
Valoscript extends ECMAScript 5 object model transparently for
manipulating valospace resources. The valoscript interpreter creates
events
The class of all chronicle event log entries
from all valospace resource
modification side-effects and groups all such side effects into
transactions. Valoscript retains ECMAScript 5 syntax and semantics.
| ||
| sourcerer | @valos/sourcerer | 0.37.0-prerelease.0 | PRIMARY INTRODUCTORY WORKSPACE VALOSPACE ONTOLOGY |
| Title: | ValOS Sourcerer API, schema | ||
| Introduction: |
| ||
| @valos/kernel-vault | @valos/kernel-vault | 0.37.0-alpha.6 | PRIMARY INTRODUCTORY VALOSPACE ONTOLOGY |
| Title: | Valos introduction and valospace API reference | ||
| Introduction: |
'Valos extends boundlessly across the valospace-time fabric.'(*)
-> Vertically: as a full application development solution valos radically simplifies the semantic web technology stack. -> Horizontally: as a global, decentralized ecosystem valos eases cross-organization interfacing. -> In depth: with its isomorphic resource model valos blurs the boundary between frontends and backends. -> Temporally: valos unifies document state and change updates into seamless event streams, *chronicles*.
The three traditional roles of application developer, systems operator
and project manager have their own unique characteristics in valos
ecosystem and are called valonaut, technician and voyager respectively.
Each role has a detailed (*) how-to guide which are linked and briefly
introduced below. The roles support each other and the guides reflect
this.
How do Valonauts develop valospace apps for users?
As a valonaut you create, share and deploy web content and
interactive applications fully from inside valospace.
You use a web editor called Zero and with it employ
traditional web technologies; HTML5, CSS and the Javascript
dialect valoscript
The skills you learn to do this are like cycling or writing - they
are used to support your other interests. While you don't need to
become a professional you certainly can!
How do Technicians deploy and maintain the valos fabric infrastructure?
As a technician you develop and operate the ValOS fabric, the globally distributed web-like infrastructure of servers,
services and components which underlies the Valospace.
You use vlm and employ your existing,
likely professional knowledge of JavaScript, Node.js, DevOps,
backend, library and other software development skills.
You create new open source and/or proprietary node packages. These
permanently create new fabric functionalities and expand the Valospace by integrating it to old world systems.
How do Voyagers understand valos capabilities in order to make decisions?
As a voyager you have stakes that matter. Whether you were to
invest on a ValOS collaborator as a financier, to adopt ValOS as
technology as an executive or just to commit your personal time and
energy on a ValOS project you need to see forward.
To make sound decisions and to position yourself proactively you
need to understand the big picture and philosophy of the ValOS
ecosystem. Only then you can enlighten others.
You use tailored but real-world ValOS demo setups to illustrate
how ValOS a solution could be configured to meet the needs at hand.
Your audience can be your customer, your team or even just
yourself.
| ||
| Name | Package | Version | Tags |
|---|---|---|---|
| raem | @valos/raem | 0.37.0-prerelease.0 | PRIMARY WORKSPACE VALOSPACE ONTOLOGY |
| Title: | ValOS Resources And Events Model (ValOS-RAEM) API, schema and ontology | ||
| Valospace abstract: |
The 'VRaem' namespace describes the @valos/raem library public API.
| ||
| script | @valos/script | 0.37.0-prerelease.0 | PRIMARY INTRODUCTORY WORKSPACE VALOSPACE ONTOLOGY |
| Title: | ValOS Script API, schema | ||
| Valospace abstract: |
The 'VScript' namespace describes the @valos/sourcerer API.
| ||
| sourcerer | @valos/sourcerer | 0.37.0-prerelease.0 | PRIMARY INTRODUCTORY WORKSPACE VALOSPACE ONTOLOGY |
| Title: | ValOS Sourcerer API, schema | ||
| Valospace abstract: |
The 'VSourcerer' namespace describes the @valos/sourcerer library public API.
| ||
| space | @valos/space | 0.37.0-prerelease.0 | PRIMARY WORKSPACE VALOSPACE ONTOLOGY |
| Title: | @valos/space library workspace | ||
| Valospace abstract: |
The 'V' namespace defines the valospace resource types and fields.
| ||
| @valos/kernel-vault | @valos/kernel-vault | 0.37.0-alpha.6 | PRIMARY INTRODUCTORY VALOSPACE ONTOLOGY |
| Title: | Valos introduction and valospace API reference | ||
| Valospace abstract: |
The 'V' namespace defines the valospace resource types and fields.
| ||
| Name | Package | Version | Tags |
|---|
| Name | Package | Version | Tags |
|---|---|---|---|
| log | @valos/log | 0.37.0-prerelease.0 | PRIMARY WORKSPACE FABRIC SPECIFICATION ONTOLOGY |
| Title: | @valos/log library workspace | ||
| Fabric abstract: |
The fabric storage and transport layer vocabulary that both specifies
the ValOS event log and aspects structure and is used to express the
content and behaviors of individual chronicles.
| ||
| plot | @valos/plot | 0.37.0-prerelease.0 | PRIMARY WORKSPACE FABRIC SPECIFICATION ONTOLOGY |
| Title: | @valos/plot library workspace | ||
| Fabric abstract: |
The vocabulary for defining the hierarchical ValOS identifiers and for
extending them with new step semantics
| ||
| revdoc | @valos/revdoc | 0.37.0-prerelease.0 | PRIMARY WORKSPACE FABRIC ONTOLOGY |
| Title: | ReVDoc - ReSpec document VDoc extension | ||
| Fabric abstract: |
'VRevdoc' namespace provides vocabulary and definitions which are
tailored for emitting ReSpec html output documents.
| ||
| sbomdoc | @valos/sbomdoc | 0.37.0-prerelease.0 | PRIMARY WORKSPACE FABRIC ONTOLOGY |
| Title: | SBoMDoc - Software Bill of Materials VDoc extension | ||
| Fabric abstract: |
'VSbomdoc' namespace provides vocabulary and definitions which are
tailored for representing CycloneDX SBoM analysis semantic content.
| ||
| state | @valos/state | 0.37.0-prerelease.0 | PRIMARY WORKSPACE FABRIC SPECIFICATION ONTOLOGY |
| Title: | @valos/state library workspace | ||
| Fabric abstract: |
The vocabulary for defining the ValOS state core model and for
extending it with new types and fields.
| ||
| twindoc | @valos/twindoc | 0.37.0-prerelease.0 | PRIMARY WORKSPACE FABRIC ONTOLOGY |
| Title: | TwinDoc - Valospace Hypertwin VDoc extension | ||
| Fabric abstract: |
'VTwindoc' namespace provides vocabulary for defining hypertwin
mappings and configurations; actual hypertwin content is represented
using the valos core ontologies and possible extension content
ontologies.
| ||
| vdoc | @valos/vdoc | 0.37.0-prerelease.0 | PRIMARY WORKSPACE FABRIC SPECIFICATION ONTOLOGY |
| Title: | VDoc - ValOS document interchange specification | ||
| Fabric abstract: |
'VDoc' namespace specifies the vocabulary for the human facing
document structure of the valos document interchange format.Human facing structure includes primitives such as chapters, titles,
lists, tables, cross-references etc.: primitives which are sufficiently
common and meaningful across all types of documents.
VDoc core ontology explicitly does not specify any semantic meanings
outside the document structure itself.
| ||
| Name | Package | Version | Tags |
|---|---|---|---|
| log | @valos/log | 0.37.0-prerelease.0 | PRIMARY WORKSPACE FABRIC SPECIFICATION ONTOLOGY |
| Title: | @valos/log library workspace | ||
| Specification abstract: |
Specifies the ValOS event log JSON-LD format and the 'VLog' namespace
The event log is sequence of
event resources
The class of all chronicle event log entries
.
An event resource is a map of semantically different
aspects
The class of resources which contain a set of attributes of a single
lifecycle aspect of some chronicle event as it progresses through the
proclamation lifecycle.
. Each aspect represents some role or lifecycle phase of the event and
is a map of attributes that relate to that role. Most notable one is
the
delta aspect
The class of resources which contain the state delta payload of some
chronicle event.
which defines the
actual state change payload of the event.
The VLog namespace together with
VState:
The vocabulary for defining the ValOS state core model and for
extending it with new types and fields.
VPlot:
The vocabulary for defining the hierarchical ValOS identifiers and for
extending them with new step semantics
and
VValk:
The vocabulary for defining ValOS computations and for
adding defining new semantics to it.
namespaces forms the
infrastructural foundation or the fabric of the valospace.VLog provides the temporal dimension and thus makes change
and reactions possible.
| ||
| plot | @valos/plot | 0.37.0-prerelease.0 | PRIMARY WORKSPACE FABRIC SPECIFICATION ONTOLOGY |
| Title: | @valos/plot library workspace | ||
| Specification abstract: |
ValOS Plots ('VPlots') are *identifier-query* strings with recursive
grammar with extensible semantics and a limited character set that
makes them easily URI embeddable.
Generally speaking a query which always resolves to the same resource
can be used as an identifier for that resource. VPlot is a format for
expressing queries in an identifier-friendly string syntax. VPlot only
provides primitives for query structure. The actual query semantics are
specified by the semantic ontology terms that are used in the vplots.
In ValOS context they are used as resource identifiers, valospace
queries, but also as a deterministic JSON serialization,
an intermediate language for computation, a configuration language,
JSON-LD interactions and more.
VPlot together with
VState:
The vocabulary for defining the ValOS state core model and for
extending it with new types and fields.
VLog:
The fabric storage and transport layer vocabulary that both specifies
the ValOS event log and aspects structure and is used to express the
content and behaviors of individual chronicles.
and
VValk:
The vocabulary for defining ValOS computations and for
adding defining new semantics to it.
form the infrastructural foundation ie. the fabric of the valospace.
| ||
| state | @valos/state | 0.37.0-prerelease.0 | PRIMARY WORKSPACE FABRIC SPECIFICATION ONTOLOGY |
| Title: | @valos/state library workspace | ||
| Specification abstract: |
Provides the ValOS resource state specification and the 'VState' ontology namespace
The VState namespace together with
VLog:
The fabric storage and transport layer vocabulary that both specifies
the ValOS event log and aspects structure and is used to express the
content and behaviors of individual chronicles.
,
VPlot:
The vocabulary for defining the hierarchical ValOS identifiers and for
extending them with new step semantics
and
VValk:
The vocabulary for defining ValOS computations and for
adding defining new semantics to it.
namespaces form the
infrastructural foundation (the fabric) of the valospace.VState provides the data model and so enables structure and
meanings.
| ||
| vdoc | @valos/vdoc | 0.37.0-prerelease.0 | PRIMARY WORKSPACE FABRIC SPECIFICATION ONTOLOGY |
| Title: | VDoc - ValOS document interchange specification | ||
| Specification abstract: |
This document specifies VDoc, a a JSON-LD-based documentation
human-machine-valospace interchange format.
| ||
| Name | Package | Version | Tags |
|---|---|---|---|
| sbom | @valos/kernel-vault | 0.37.0-alpha.6 | PRIMARY SBOM |
| Title: | @valos/kernel-vault@0.37.0-alpha.6 Software Bill of Materials | ||
| Abstract: |
This document is an autogenerated CycloneDX SBoM document
| ||
| kernel | @valos/kernel | 0.37.0-prerelease.0 | PRIMARY DOMAIN ONTOLOGY TECHNICIAN |
| Title: | @valos/kernel domain content reference | ||
| Abstract: |
@valos/kernel domain includes all core infrastructure components of ValOS -
the Valaa Open System.
These components are hosted at the npmjs repository within @valos namespace.
These components are developed at the valos git repository.
| ||
| type-vault/AssortedTutorials | @valos/type-vault | 0.37.0-prerelease.0 | PRIMARY HOW_TO |
| Title: | Assorted tutorials | ||
| Abstract: |
| ||
| Name | Package | Version |
|---|---|---|
| tool | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | 'tool' workspace type is deprecated. Tools are a toolset implementation detail. A tool is similar to a toolset in that it can have its own workspace specific configurations. A tool differs from a toolset in that it cannot be standalone; it doesn't appear in listings, its always part of one or more toolsets and its toolsets.json config stanzas are placed under its parent toolset stanzas. The main case for tools and toolsets separation came from the release deployment system of opspaces, where the modularity and granular semantic versioning of tool packages allows for more efficient and robust deployments. Tool workspaces allows splitting complex toolsets into separate tools with different deployment logic. Infrastructure code which changes rarily can be placed under tool packages with naive deployment logic which relies on the tool package version number only. Frequently changing configs can be managed by the toolset workspace itself but even it can then use tool workspaces to source in commands and other resources to help with the deployment management. Additionally because the tool configuration is always inside its parent toolset config this allows the same tool be used by several different toolsets in a single workspace. Because of this all tool commands must have an option for '--toolset=<@scope/toolsetname>' which uses yargs.vlm.toolset as its default value. | |
| toolset | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | Construct a collection of valma tools that other workspaces can select and use. A toolset is a package that can be selected by any valos workspace during 'vlm init'. More precisely: 1. given that the toolset is registered to a domain, and 2. the workspace is set up to use this domain (f.ex. during 'vlm init'), then 2. the 'vlm configure' presents the toolset as a selectable option, and if selected, 3. the toolset is added as a devDependency to the workspace, and also 4. a toolset configuration section with "inUse: true" is added to the workspace 'toolsets.json' using the toolset name as the key, and finally 5. the toolset configuration valma command is called by 'vlm configure' This makes all valma commands and other primitives of the toolset available for the workspace and also allows these commands to manage their workspace-specific configurations. | |
| domain | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | Curate a valos discovery domain of packages. A domain package provides a set of valma commands for defining and managing a ValOS domain. Specific domain workspaces then: 1. shall provide domain package (de)registration via .configure/.<domain>/{,de}register-package 2. can provide new workspace types via .select/.type/* 3. can provide new toolsets via .select/.toolsets/{,.domain/<domain>/}{,.type/<type>/}{,.workspace/<name>}/**/* Notably the package (de)registration should provide means for any new domain toolset packages to request the addition of their toolset configure command to the domain domain. Idiomatic way to implement this is a domain command which issues a PR against the source control repository of the domain package. | |
| type | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | Declare a new valos type. A valos type is a name that can be chosen as a package.json:valos.type during workspace init. Each type serves a particular purpose which is described in the type introduction. Each type is optionally associated with a specific type toolset. This toolset is automatically added as an always-in-use dependency and provides commands and library code for the workspace. As an example the type 'worker' adds the toolset @valos/type-worker which provides template files and shared code for managing perspire gateway execution environments. As a bit more self-referential example the type 'toolset' adds the toolset @valos/type-toolset. This type toolset provides commands and shared code for managing the valos toolset functionality itself. Finally, the type 'type' is the type of all type toolsets themselves. Initializing a new workspace with type 'type' introduces a new type to the ValOS ecosystem. | |
| opspace | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | Dev a singular but repeated Ops 'build-release' / 'deploy-release' task. An opspaces workspace is used to for configuring, deploying, updating, monitoring and diagnosing all types of live infrastructure resources. Opspaces rely heavily on various toolsets to get their job done. Opspaces rarily are published and packages and typically reside in "opspaces/*" vault workspace directory | |
| library | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | Develop a publishable software components package. A library workspace contains arbitrary ES5 source code and exposes a API via package.json .main stanza (usually index.js). A library can provide convenience valma commands but unlike toolsets a library cannot have workspace local configurations. Library workspaces are almost always published as a packages and typically reside in "packages/*" vault workspace directory. | |
| spindle | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | Develop a valos gateway plugin. A gateway spindle extends inspire and perspire gateways with various functionalities. Core spindles provide new resource schemas, media decoders, protocol schemes, external APIs, valosheath APIs, etc. Custom spindles can be plugged into workers for arbitrary code but are only available on inspire if they are explicitly bundled with it. Spindles load their configuration from the gateway revelation. When a particular spindle is configured for a perspire worker its configuration is typically placed as a tool the toolset. | |
| worker | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | Execute perspire gateway as a Node.js process. A worker workspace is used to launch and manage a particular service process. The workspace files contain configuration and data used by the process. This data can include even dynamic runtime data. A worker workspace is fully agnostic to version control solutions: - script-generated workers, where worker is locally spawned by scripts - clone-and-forget workers, where worker is cloned from a versioned upstream repository, has its configuration locally customized and local content potentially overridden. No further download sync is expected nor will workers push updates back upstream. Each clone represents its own computation. - synchronized workers, where the versioned repository itself represents the worker process. Worker workspace shards (there can be many if the computation is parallelizable) are still cloned from the versioned upstream. Unlike with clone-and-forget workers the synchronized worker workspaces keep themselves in sync with upstream configuration and data changes and adjust their computation accordingly. Sync workers shards can even push results back to the versioned repository if appropriate. | |
| vdoc-extension | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | Extend valos document spec with domain specific vocabulary and functionality. A vdoc-extension workspace contains the extension specification and supporting libraries for a VDoc extension. It inherits library workspace characteristics but has a specific structure and initial templates which is useful for VDoc extensions in specific. | |
| vault | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | Maintain many workspaces in a single version controlled mono-repository. A vault is a *monorepository* which contains multiple sub-workspaces of various types. Vaults are used to group packages with high cohesion together so that development, testing, review and deployment workflows can be done within a single repository when feasible. Vault is primarily an organizational unit and is hosted in a single version control repository. All sub-workspaces have identical access rights for all contributors. All sub-workspaces must have similar licences. Exceptions to this must be clearly noted both in the exceptional workspace root document as well as in the vault root document. A vault can have different types of workspaces in it; some of these (such as libraries, toolsets) may be published to repositories as *packages* so that they can be used as dependencies for other workspaces. Others are only local and used for other purposes; *opspaces* contain configurations and tools for managing infrastructure configurations and *workers* contain files for spawning local processes. No matter what the valos type of the domain all share important qualities: they can have package dependencies, are versioned and are managed by valma. A vault often also manages a *domain* for the packages it publishes via a *domain package*. Domain is a discovery construct. When a domain package is added as a devDependency to some external package then valma will be able to list and configure any applicable toolsets and other workspaces for this package. | |
| Name | Package | Version |
|---|---|---|
| @valos/type-toolset | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | Make current workspace selectable as a toolset for other workspaces. A toolset is a package that can be selected by any valos workspace during 'vlm init'. More precisely: 1. given that the toolset is registered to a domain, and 2. the workspace is set up to use this domain (f.ex. during 'vlm init'), then 2. the 'vlm configure' presents the toolset as a selectable option, and if selected, 3. the toolset is added as a devDependency to the workspace, and also 4. a toolset configuration section with "inUse: true" is added to the workspace 'toolsets.json' using the toolset name as the key, and finally 5. the toolset configuration valma command is called by 'vlm configure' This makes all valma commands and other primitives of the toolset available for the workspace and also allows these commands to manage their workspace-specific configurations. | |
| @valos/web-spindle | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | Project http/s requests to valospace-fabric via a gateway plugin. Selects web-spindle as a worker toolset. | |
| @valos/toolset-revealer | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | Run 'vlm rouse-revealer' to serve local inspire sites with webpack-dev-server. This toolset enables valma command 'rouse-revealer' for deploying a local dev environment for inspire gateway revelations. Sets up the webpack entry and output config as webpack.config.js in the workspace root, which combines shared revealer config from @valos/toolset-revealer/shared/webpack.config.js, local toolset config and any customizations in the root webpack.config.js itself. | |
| Name | Package | Version |
|---|---|---|
| copy-template-files | @valos/kernel | 0.37.0-prerelease.0 |
| Introduction: | Copy toolset template files to the workspace. Copy toolset template files to the workspace. When selected for a toolset this tool will copy all template files from the toolset package templates/ sub-directory to the current workspace. | |
| docs | @valos/type-vault | 0.37.0-prerelease.0 |
| Introduction: | Generate /docs html files from all vault revdocs files. This type-vault tool provides commands for (re)generating the /docs folder from document sources present in the local workspaces, notably all revdoc documents matching glob '*.revdoc{,.test}.js'. Additionally this tool can be configured to regenerate all docs on (pre)release time. | |
| domain | @valos/type-vault | 0.37.0-prerelease.0 |
| Introduction: | Setup a type-domain package for curating the domain of this vault. This type-vault tool enables the domain management and (re)generation of docs/index.html domain summary revdoc document. | |
| enable-babel | @valos/type-vault | 0.37.0-prerelease.0 |
| Introduction: | Transpile the library files on assembly with the vault babel.config.js. This tool enables babel transpilation for a library workspace when 'vlm assemble-packages' is executed in the surrounding vault workspace. | |
| Name | |
|---|---|
| clean-vault | |
| Description: | Clean various more or less transient vault files and subdirectories |
| Introduction: | Clean various more or less transient vault files and subdirectories. By default the three elements installed by 'yarn install' are cleaned: 1. workspace packages by 'lerna clean --yes' 2. yalc local dependencies by 'yalc remove --all' 3. vault root node_modules by 'rm -rf' In addition, dist/ can be removed with --dist in preparation for a clean slate publish/deploy ops. Be mindful that all of dist/ will be removed. yarn.lock can be removed with --yarn in preparation for persisted dependency updates. |
| compose-revelation | |
| Description: | Compose revealer bundles based on the revealer toolset config |
| Introduction: | Compose revealer bundles based on the revealer toolset config. |
| rouse-revealer | |
| Description: | Launch a webpack-dev-server at localhost serving a local revelation |
| Introduction: | Launch a webpack-dev-server at localhost serving a local revelation. The revelation consists of two parts: webpack output and static files. Webpack output is configured by the project root webpack.config.js and the static files are served from --content-base. If this --content-base doesn't exist it is created by copying all files from the directory(s) provided by --content-source. |
| build-release | |
| Description: | Build a new release of this opspace |
| Introduction: | Build a new release of this opspace. This command prepares, builds and tests a new opspace release locally without making external changes. This forms the first part of the opspace deployment process. The second half is `deploy-release` which performs the actual deployment process. This command resolves a local 'releasePath' for the build and then invokes all release-build sub-commands as follows: vlm .release-build/${toolsetGlob || "**/*"} --target=${releasePath} ${rest} These sub-commands (which can be local opspace commands or commands provided by opspace toolset dependencies) then (re)build the actual build artifacts under the target path. |
| deploy-release | |
| Description: | Deploy previously built releases to their deployment targets |
| Introduction: | Deploy previously built releases to their deployment targets. This command is second part of the two-part deployment with build-release building the release. |
| assemble-packages | |
| Description: | Assemble all current modified vault packages (preparing for publish) |
| Introduction: | Assemble all current modified vault packages (preparing for publish). Uses lerna to handle the monorepo sub-packages update detection, versioning, and git interactions. Configuration for lerna is in lerna.json: notably the version increase semantics is configured there. Lerna is not used for constructing the actual packages. This is done by a flat recursive cp to the target at the moment. Invokes babel for all projects with babel.config.js in their root. If the vault has a shared babel.config.js for all packages, a symlink from this root to each project should be created. When assembling lerna will automatically update the shared version for all packages and their cross-dependencies and make a git commit and git tag for the new version. This behaviour can be omitted with --no-versioning. Iterative development with yalc and publish-packages: Once a set of packages has been been built to the target, run: 'vlm publish-packages --publisher=yalc' This will make the package assemblies available in a local yalc 'registry'; see https://github.com/whitecolor/yalc for more details on how to use such packages by other depending packages. Reassembling and pushing those changes through yalc to dependents can be done with: 'vlm assemble-packages --reassemble --post-execute="cd $ASSEMBLY_TARGET && yalc push --no-sig"' This allows packages to be developed iteratively locally while having other packages depend and be tested against them. |
| generate-domain-summary | |
| Description: | Generate the domain components summary file for the domain root revdoc |
| Introduction: | Generate the domain components summary file for the domain root revdoc. |
| release-vault | |
| Description: | Prepare, commit and potentially publish a new release of vault packages |
| Introduction: | Prepare, commit and potentially publish a new release of vault packages. Prepares a release to a new or existing release/develop branch based on given options and current environment. Prepares the release by first running sanity checks, then cleaning and reinstalling intermediate files like node_modules, yarn workspaces, yarn.lock and dist/ and finally requires all test suites and lint to pass without errors. Once preparation is done creates a new release commit and tag using 'lerna version'. If --publish is not explicitly given then the final publish step must be manually performed. In this case a pre-publish phase is done which prepares the manual publish command instructions in the results output. Will invoke valma command hooks between phases as follows: 1. 'vlm .release-vault/.prepared-hooks/{**/,}* --summary=<obj>' after successful preparation 2. 'vlm .release-vault/.committed-hooks/{**/,}* --summary=<obj>' after successful commit 3. 'vlm .release-vault/.pre-published-hooks/{**/,}* --summary=<obj>' after successful pre-publish 4. 'vlm .release-vault/.published-hooks/{**/,}* --summary=<obj>' after successful publish |
| publish-packages | |
| Description: | Publish package assemblies to their registries |
| Introduction: | Publish package assemblies to their registries. |
| regenerate-docs | |
| Description: | Regenerate all configured /docs content |
| Introduction: | Regenerate all configured /docs content. |
| write-revdoc | |
| Description: | Write a new revdoc source code file |
| Introduction: | Write a new revdoc source code file. |
| bundle-revelation | |
| Description: | Bundles chronicles and other preloadable content into a revela.json |
| Introduction: | Bundles chronicles and other preloadable content into a revela.json. Lists the chronicles listed in the revelation-path prologue. Preloads their event logs and media contents using vlm export-chronicle. Bundles these back into revelation files and adds them into prologue chronicleVLogs, chronicleMediaInfos, bvobInfos and bvobBuffers sections. |
| export-chronicle | |
| Description: | Exports given chronicle as file hierarchy under target directory |
| Introduction: | Exports given chronicle as file hierarchy under target directory. Uses perspire. |
| perspire | |
| Description: | Launch a headless worker gateway for virtual DOM ValOS computation jobs |
| Introduction: | Launch a headless worker gateway for virtual DOM ValOS computation jobs. |
| configure | |
| Description: | Configure the current ValOS workspace type, domain and all configurables |
| Introduction: | Configure the current ValOS workspace type, domain and all configurables. Configures type and domain, selects and stows toolsets, tools and other configurables and finally configures them. |
| status | |
| Description: | Display the status of the current valos workspace |
| Introduction: | Display the status of the current valos workspace. If toolsetGlob is specified the status is limited to status scripts matching '.status/*{toolsetGlob}*/**/*', otherwise all status scripts by '.status/**/*' are used. |
| draft-command | |
| Description: | Draft and possibly export a new valma command script |
| Introduction: | Draft and possibly export a new valma command script. The new command is drafted as a local valma.bin/ command with the source file in valma/, making it the highest priority command and immediately available. With --import a existing exported script is copied for local editing and development. |
| @ | |
| Description: | Execute a package bin command within valma context interactively |
| Introduction: | Execute a package bin command within valma context interactively. Execute a package bin command within valma context interactively. This is the command line shim to valma script vlm.interact. Like 'npx -c' it executes a regular command exported by some package dependency to the node_modules/.bin/ folder. Unlike 'npx' which only searches the current directory and the global cache '@' prepends all available valma pools to env.PATH, innermost pool first. |
| init | |
| Description: | Initialize the current directory as a ValOS workspace from scratch |
| Introduction: | Initialize the current directory as a ValOS workspace from scratch. This command will interactively create and configure a new valma workspace in the current working directory from scratch. Valma init has following interactive phases: 1. Initialization of package.json via 'yarn init' 2. Configuration of workspace valos.type and .domain via 'vlm .configure/.valos-stanza' 3. Addition of new known domains via 'yarn add --dev (-W)' 4. Selection of in-use toolsets from available toolsets via 'vlm select-toolsets' 5. Configuration of in-use toolsets and tools via 'vlm configure' |
| Name | Version | License |
|---|---|---|
| valma | 0.37.0-alpha.6 | MIT |
| Description: | A ValOS CLI tool for discovering and executing context-dependent command scripts | |
| Introduction: | ||
| @valos/toolset-revealer | 0.37.0-alpha.6 | MIT |
| Description: | Tools for building revelations both for development and deployment purposes | |
| Introduction: | ||
| Name | Version | License |
|---|---|---|
| @valos/engine | 0.37.0-alpha.6 | MIT |
| Description: | ValOS Engine API and Schema | |
| Introduction: | ||
| @valos/gateway-api | 0.37.0-alpha.6 | MIT |
| Description: | Minimal footprint ValOS Gateway API local forwards | |
| Introduction: | ||
| @valos/hypertwin | 0.37.0-alpha.6 | MIT |
| Description: | ValOS Hypertwin Specifications and Tools Library | |
| Introduction: | ||
| @valos/inspire | 0.37.0-alpha.6 | MIT |
| Description: | ValOS Inspire application gateway | |
| Introduction: | ||
| @valos/raem | 0.37.0-alpha.6 | MIT |
| Description: | ValOS Resources And Events Model (ValOS-RAEM) API, schema and ontology | |
| Introduction: | ||
| @valos/script | 0.37.0-alpha.6 | MIT |
| Description: | ValOS Script API, schema | |
| Introduction: | ||
| @valos/sourcerer | 0.37.0-alpha.6 | MIT |
| Description: | ValOS Sourcerer API, schema | |
| Introduction: | ||
| @valos/tools | 0.37.0-alpha.6 | MIT |
| Description: | ValOS Tools API | |
| Introduction: | ||
| Name | Version | License |
|---|---|---|
| @valos/kernel | 0.37.0-alpha.6 | MIT |
| Description: | @valos/kernel domain | |
| Introduction: | ||
| Name | Version | License |
|---|---|---|
| @valos/revdoc | 0.37.0-alpha.6 | MIT |
| Description: | ReVDoc - ReSpec document VDoc extension | |
| Introduction: | ||
| @valos/sbomdoc | 0.37.0-alpha.6 | MIT |
| Description: | SBoMDoc - Software Bill of Materials VDoc extension | |
| Introduction: | ||
| @valos/twindoc | 0.37.0-alpha.6 | MIT |
| Description: | TwinDoc - Valospace Hypertwin VDoc extension | |
| Introduction: | ||
| @valos/vdoc | 0.37.0-alpha.6 | MIT |
| Description: | VDoc - ValOS document interchange specification | |
| Introduction: | ||
| Name | Version | License |
|---|---|---|
| @valos/web-spindle | 0.37.0-alpha.6 | MIT |
| Description: | A spindle for structured ValOS Web APIs | |
| Introduction: | ||
| Name | Version | License |
|---|---|---|
| @valos/type-spindle | 0.37.0-alpha.6 | MIT |
| Description: | The ValOS 'spindle' workspace type toolset | |
| Introduction: | ||
| @valos/type-opspace | 0.37.0-alpha.6 | MIT |
| Description: | The ValOS 'opspace' workspace type toolset | |
| Introduction: | ||
| @valos/type-vault | 0.37.0-alpha.6 | MIT |
| Description: | The ValOS 'vault' workspace type toolset | |
| Introduction: | ||
| @valos/type-worker | 0.37.0-alpha.6 | MIT |
| Description: | The ValOS 'worker' workspace type toolset | |
| Introduction: | ||
| @valos/type-domain | 0.37.0-alpha.6 | MIT |
| Description: | The ValOS domain workspace type toolset | |
| Introduction: | ||
| Prefix | IRI |
|---|---|
| rdf | http://www.w3.org/1999/02/22-rdf-syntax-ns# |
| rdfs | http://www.w3.org/2000/01/rdf-schema# |
| xsd | http://www.w3.org/2001/XMLSchema# |
| owl | http://www.w3.org/2002/07/owl# |
| dc | http://purl.org/dc/elements/1.1/ |
| VKernel | https://valospace.org/kernel/0# |
| VPlot | https://valospace.org/plot/0# |
| VState | https://valospace.org/state/0# |
| VValk | https://valospace.org/valk/0# |
| VLog | https://valospace.org/log/0# |
| VEngine | https://valospace.org/engine/0# |
| rdfs:subClassOf | description |
|---|---|
#Property | |
| rdf:Property | The class of properties which are defined by the ValOS kernel domain ontologies. |
#Concept | |
| rdf:Property | The class of individuals which represent documentable concepts with associations to . |
#API | |
| VKernel:Concept The class of individuals which represent documentable concepts with associations to . | The class of concepts which represent application programming interfaces. |
| rdfs:domain | rdfs:range |
|---|
| VRevdoc:brief | rdfs:subClassOf |
|---|
| rdfs:domain | rdfs:range | rdf:type | rdfs:subPropertyOf | VState:coupledToField |
|---|
| Comment | rdf:type |
|---|
| rdf:type | rdfs:subClassOf |
|---|---|
#Class | |
| rdfs:Class | rdfs:Class |
| description | The class of classes which are defined by the ValOS kernel domain ontologies. |
| Term | Definition | @id | @type | @container |
|---|---|---|---|---|
| restriction | ||||
| @base | https://valospace.org/kernel/0# |