typedly/settings

Version: v0.3.0

A TypeScript type definitions package for settings.

Table of contents

• Installation
• Api
  • Interface
    • Other
      • ValueSetting
      • Settings
  • Type
    • DisplaySelectedSettings
    • OptionalField
    • RequiredField
    • SelectableSettings
• Configuration System Overview
• Contributing
• Support
• Code of Conduct
• Git
  • Commit
  • Versioning
• License

Installation

Install peer dependencies

npm install @typedly/length @typedly/pattern --save-peer

Install the package

npm install @typedly/settings --save-peer

Api

// Interface.
import {
  // Value.
  ValueSetting,
  // Settings.
  Settings,
} from '@typedly/settings';

// Type.
import {
  // Settings.
  DisplaySelectedSettings,
  SelectableSettings,
  // Settings fields.
  OptionalField,
  RequiredField,
} from '@typedly/settings'; 

Interface

ValueSetting

value-setting.interface.ts

import { ValueSetting } from '@typedly/settings';

export const valueSettings: ValueSetting<'the value'> = {
  value: 'the value'
}

Settings

settings.interface.ts

import { Settings } from '@typedly/settings';

export const settings: Settings<
  'abcd1234',
  number,
  27,
  34,
  RegExp
> = {
  // LengthSettings
  length: { min: 27, max: 34 },
  // PatternSettings
  pattern: {
    lowercase: true,
    numeric: true,
    regexp: /[a]g/g,
    special: true,
    uppercase: true,
  },
  // ValueSettings
  value: 'abcd1234',
}

Type

DisplaySelectedSettings

display-selected-settings.type.ts

import { DisplaySelectedSettings } from '@typedly/settings';

OptionalField

optional-field.type.ts

import { OptionalField } from '@typedly/settings';

RequiredField

required-field.type.ts

import { RequiredField } from '@typedly/settings';

SelectableSettings

selectable-settings.type.ts

import { SelectableSettings } from '@typedly/settings';

export const settings: SelectableSettings<
  ['length', 'value'],
  'abcd1234',
  number,
  27,
  34,
  RegExp
> = {
  // LengthSettings
  length: { min: 27, max: 34 },
  // PatternSettings - not allowed
  // pattern: {
  //   lowercase: true,
  //   numeric: true,
  //   regexp: /[a]g/g,
  //   special: true,
  //   uppercase: true,
  // },
  // ValueSettings
  value: 'abcd1234',
}

Configuration System Overview

This library uses a structured approach for handling settings, options, and configuration, ensuring strong typing and clarity, as follows.

Naming Convention for Settings Interfaces

To promote clarity and consistency, the following naming conventions for settings interfaces are used:

• Singular (Setting): Represents a single, specific configuration option.

  • Example:
    LengthSetting describes the settings for a single aspect, such as the allowed length of a value.
    • MinLengthSetting describes the minimum length requirement.
    • MaxLengthSetting describes the maximum length requirement.

• Plural (Settings): Represents a group of related settings, often an object containing multiple Setting properties.

  • Example:
    LengthSettings groups together related settings, such as both minimum and maximum length requirements:

export interface LengthSettings {
  min: MinLengthSetting;
  max: MaxLengthSetting;
}
export interface LengthSetting {
  length: LengthSettings;
}

Summary Table

| Name | Meaning | Example Usage | |--------------------|----------------------------------------|----------------------------------------------| | LengthSetting | Single setting (e.g., length) | const min: LengthSetting = { ... } | | MinLengthSetting | Specific single setting (min length) | const min: MinLengthSetting = { ... } | | LengthSettings | Group of related settings (plural) | const settings: LengthSettings = { ... } |

Settings

Settings types define the shape of configuration data with all fields required at the top level, but can be omitted by setting them to undefined. They represent the complete set of parameters that can be provided, ensuring that all necessary information is present. The settings may include option objects whose own fields can be optional, even though top-level field in the settings is required, but may be set to undefined.

• Represents the “full shape” of what can be configured.
• Used for validation, documentation, or generating configuration forms.
• Unlike Options, Settings ensure every possible field is present, event if unset.

Example:

// Represents the concrete settings for a length configuration.
export interface Length<
  Value extends number | undefined = number | undefined,
  Min extends number | undefined = number | undefined,
  Max extends number | undefined = number | undefined
> {
  /**
   * @description Represents expected length of the value, also between min and max.
   * @type {Value}
   */
  value: Value;

  /**
   * @description Represents the minimum length of the value.
   * @type {Min}
   */
  min: Min;

  /**
   * @description Represents the maximum length of the value.
   * @type {Max}
   */
  max: Max;
}

Options

Options types are based on the corresponding settings, but make all or some fields optional.
Use options when you want to allow partial configuration, for example for incremental setup or user input that may not specify all values.

Example:

export interface LengthOptions<
  Value extends number | undefined = number | undefined,
  Min extends number | undefined = number | undefined,
  Max extends number | undefined = number | undefined
> extends OptionalField<Length<Value, Min, Max>> {}

Configuration

Configuration types represent the result of applying/saving settings and options.
They often reflect the actual configuration that is active at runtime, possibly after defaults and validation have been applied.

Example:

export type LengthConfiguration = LengthSettings;

Summary Table

| Type | Fields Required? | Usage | |---------------|-------------------|-------------------------------------------| | Settings | All | Full specification of settings | | Options | Some/All optional | Partial or user-provided configuration | | Configuration | All (finalized) | Saved, validated, or runtime configuration|

Contributing

Your contributions are valued! If you'd like to contribute, please feel free to submit a pull request. Help is always appreciated.

Support

If you find this package useful and would like to support its and general development, you can contribute through one of the following payment methods. Your support helps maintain the packages and continue adding new.

Support via:

• Stripe
• Revolut
• GitHub
• DonorBox
• Patreon

or via Trust Wallet

• XLM
• USDT (BEP20)
• ETH
• BTC
• BNB

Thanks for your support!

Code of Conduct

By participating in this project, you agree to follow Code of Conduct.

GIT

Commit

• AngularJS Git Commit Message Conventions
• Karma Git Commit Msg
• Conventional Commits

Versioning

Semantic Versioning 2.0.0

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards-compatible manner, and
• PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

FAQ How should I deal with revisions in the 0.y.z initial development phase?

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

License

MIT © typedly (license)