Configuration

Relevant source files

The following files were used as context for generating this wiki page:

• WARP.md
• README.md
• deployment/README.md
• client/landing/routes/compare/memotronWheel.ts
• client/landing/memotron.io/compare/memotronWheel.ts
• client/cx/contemporaries/notion.json
• test-setup.js

Configuration in the Nucleus project is managed at multiple levels, from the high-level monorepo structure defined by Turbo to specific settings for individual products like Memotron, Pointron, and Nucleus. This system allows for shared libraries and components while enabling distinct features and deployment targets for each application.

The configuration strategy encompasses workspace structure, product-specific features, and deployment environment variables. A key aspect is the detailed definition of product features and their comparison against contemporary applications, which is managed through structured TypeScript and JSON files. This allows for dynamic generation of content, such as feature comparison wheels on product landing pages.

Monorepo and Workspace Configuration

The project utilizes a Turborepo monorepo architecture to manage its various packages and applications. The structure is designed to separate shared code from product-specific implementations.

Sources: WARP.md:10-21, test-setup.js

Directory Structure

The monorepo is organized into several key directories, each with a specific purpose. A test script (test-setup.js) is used to verify the existence of these core directories and essential configuration files like turbo.json.

The following diagram illustrates the high-level directory structure.

Workspace Verification

The test-setup.js script provides a simple way to test the Turbo workspace setup. It performs the following checks:

1. Packages Check: Verifies that all expected shared libraries exist under the packages/ directory.
2. Product Apps Check: Confirms the existence of product-specific application folders within client/products/ and checks for a package.json in each.
3. Turbo Config Check: Ensures that turbo.json and the root package.json are present.

Sources: test-setup.js:4-67

Product Configuration

Each product (Nucleus, Memotron, Pointron) has its own configuration. While a central product.config.ts is mentioned for defining menus and features, a detailed example of feature configuration is found in the landing page code for Memotron, which defines features for a comparison tool.

Sources: WARP.md:24-25, client/landing/routes/compare/memotronWheel.ts

Memotron Feature Configuration

For the Memotron product, features are meticulously defined in client/landing/routes/compare/memotronWheel.ts. This configuration is used to power a feature comparison wheel on the product's website.

The configuration is broken down into categories and a list of features.

Feature Categories

Feature categories group related features and assign a specific color for UI purposes.

Label	Color
Capture	#2A8CAB
Clipping	#4E9973
Content	#1E9B92
Curation	#D4A534
Views	#AA6A6A
Synthesis	#7E49A1
App	#4287f5

Sources: client/landing/routes/compare/memotronWheel.ts:28-35

Feature Definition Structure

Each feature is an object conforming to the IFwFeature interface. This structure contains all the necessary information to describe, rate, and compare a feature.

Property	Type	Description
label	string	The display name of the feature.
slug	string	A unique identifier for the feature.
category	MemotronFeatureCategory	The category the feature belongs to.
progress	number	A value from 0 to 1 indicating the implementation progress.
description	string	A detailed explanation of the feature.
ratingCriteria	array	A list of criteria used to rate the feature.
contemporaries	array	Comparison data against other apps (loaded separately).
isPlanned	boolean	true if the feature is not yet implemented.
isNovel	boolean	true if the feature is unique to Memotron.

Sources: client/landing/routes/compare/memotronWheel.ts:8-11, client/landing/routes/compare/memotronWheel.ts:51-1020

The following diagram shows the relationship between categories, features, and the data for contemporary products.

This diagram illustrates how feature categories group multiple features, and how each feature can be compared against multiple contemporary products through a set of specific ratings.
Sources: client/landing/routes/compare/memotronWheel.ts:8-11, client/cx/contemporaries/notion.json:1-20

Contemporary Product Configuration (Notion Example)

Data for competing products is stored in JSON files, such as client/cx/contemporaries/notion.json. This file contains general information about Notion and a feature-by-feature rating breakdown that corresponds to the slugs defined in memotronWheel.ts.

{
  "label": "Notion",
  "url": "notion.so",
  "sourcingType": "CLOSED",
  "features": [
    {
      "feature": "source",
      "rating": 0
    },
    {
      "feature": "privacy",
      "rating": 0.3,
      "notes": "Notion doesn't take offline-first approach..."
    }
  ]
}

Sources: client/cx/contemporaries/notion.json:1-20

This structured data is loaded and mapped to the corresponding features to populate the comparison views.
Sources: client/landing/routes/compare/memotronWheel.ts:1022-1052

Deployment Configuration

The project supports self-hosting for the frontend applications. Full-stack deployment, including a backend on Cloudflare, is planned for the future.

Sources: README.md:28-44

Self-Hosting Frontend

To self-host a frontend-only version of an app (e.g., Memotron), the repository must be cloned, and specific environment variables must be set before deploying to a hosting provider.

The deployment process is as follows:

Environment Variables

The following environment variables are required for building and deploying a product application.

Variable	Description	Example Value
VITE_PRODUCT	Specifies which product to build.	memotron, pointron, or nucleus
VITE_STATIC_URL	The base URL for static assets.	https://cdn.21n.co

Sources: README.md:35-39

Future Deployment Plans

The project documentation indicates that full application deployment, including the backend components on Cloudflare services (Workers, D1, R2), will be available in the future. The deployment/README.md file contains generic instructions for GitLab CI/CD, suggesting that this is the intended platform for continuous integration and deployment.

Sources: README.md:42-44, deployment/README.md:24-34