npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@hpi-schul-cloud/commons

v1.3.4

Published

Helpers and common tools for the hpi school-cloud.

Downloads

6,901

Readme

Commons

npm version Test Action Deployment Action Codacy Badge

Install

npm install @schul-cloud/commons --save

Test

npm install
npm test

Usage

Configuration

The Configuration is a singleton that can be reused to hold a configuration that is validated by JSON Schema. A JSON-Schema has to be defined as default.schema.json inside a config folder.

The configuration is build by parsing multiple sources in the following order (Last definition overrides definition from before):

  1. defaults from default.schema.json
  2. defaults from default.json (values have to be defined here, for properties required in the schema too beside the schema default)
  3. parse configuration files from environment
    1. NODE_ENV.json from config folder (defaults to development.json, if NODE_ENV is not defined - the file existence is optionally)
    2. Other environment files can be added into options.loadFilesFromEnv after NODE_ENV by default, SC_INSTANCE.
  4. .env file from execution/project root directory
  5. existing environment variables finally override everything from before.

The default schema parser options

  1. remove all options from upper sources if the schema contains the property "additionalProperties": false
  2. applying default values
  3. do a type conversion especially for string to type conversion values not defined in the json files (string to X).

Invalid input values will raise an error by default.

To enable multiple inherited objects when parsing environment variables there may be a dot notation be used. When enabled, this gets applied for export, has, and get too. Currently only __ (double underscore) is supported as separator due to the dependency dotenv and bad support of . (single dot) in many terminals.

Secrets

There exist a method printHierarchy() to print the whole hierarchy of a configuration. For security reasons, by default all values of string typed properties having secret or key in their name will be replaced with a hash-id. Same hashes identify same original values.

Use the naming convention to start secure properties with SECRET_ in their name and use type string.

Specifying Dependencies

Often specific configuration options are required based on the state of other configuration values. These dependencies can be defined using the if/then/else keywords.

In the example below the rule SERVICE_REQUIRES_OTHER rule is activated in the allOf block. The rule itself is defined in the definitions block. If the property SERVICE_PROPERTY is set to VALUE_OF_SERVICE we also require that OTHER_PROPERTY is set. Make sure that a default value is set for SERVICE_PROPERTY to avoid passing undefined to an if keyword.

Sample

default.schema.json

{
    "title": "Example Schema with dependency",
    "description": "This schema declares a dependency between two properties.",
    "additionalProperties": false,
    "type": "object",
    "properties": {
        "SERVICE_PROPERTY": {
            "type": "string",
            "enum": ["none", "VALUE_OF_SERVICE"],
            "default": "none"
        },
        "OTHER_PROPERTY": {
            "type": "string"
        }
    },
    "allOf": [
        {
            "$ref": "#/definitions/SERVICE_REQUIRES_OTHER"
        }
    ],
    "definitions": {
        "SERVICE_REQUIRES_OTHER": {
            "if": {
                "properties": {
                    "SERVICE_PROPERTY": {
                        "const": "VALUE_OF_SERVICE"
                    }
                }
            },
            "then": {
                "required": ["OTHER_PROPERTY"]
            }
        }
    }
}

default.json

{
    "$schema": "default.schema.json",
    "SERVICE_PROPERTY": "VALUE_OF_SERVICE",
    "OTHER_PROPERTY": "VALUE"
}

index.js

// Access Configuration as Singleton, using default export
// Initialization is done on first access
// uses IConfigOptions optionally defined in a sc-config.json file
import { Configuration as config } from "@schul-cloud/commons";

// Access configuration as class
// IConfigOptions can be set in constructor options
import { TestConfiguration } from "@schul-cloud/commons";
const config = new TestConfiguration(options);

// Then you may run...
config.has("key");
const before = config.toObject();
// and when the property key has been defined in the schema...
config.get("key");
config.set("key", "value");
// or updating multiple entries
config.update({...});

// suggested for testing only
config.remove("key"); // removes a single key
config.remove("key", "key2", ...); // remove multiple keys
// override the complete config (removes prior values)
config.reset(before);

Options

| Option key | Value(s) or Type | default | Description | | ---------------- | -------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | logger | any | console | a logger instance | | throwOnError | boolean | true | enable throwing an error when an undefined configuration value is requested | | notFoundValue | any | null | if throwOnError is not set true, an alternate default value may returned | | configDir | string | config | directory where schema and configuration files are located | | schemaFileName | string | default.schema.json | default schema file name | | baseDir | string | process.cwd() | path to folder where configDir is located | | ajvOptions | object | removeAdditional: 'true' useDefaults: true coerceTypes: 'array' | Schema Parser Options, see https://github.com/epoberezkin/ajv#options | | useDotNotation | boolean | true | enables dot notation for parsing environment variables (not json files!) and exporting the current config using has, get, and toObject. | | fileEncoding | string | 'utf8' | set file encoding for imported schema and configuration files | | loadFilesFromEnv | string[] | ['NODE_ENV'] | defines the order of configuration files loaded by specified environment values filename must have json extension like NODE_ENV.json | | printHierarchy | boolean | false | executes printHierarchy() right after initialization | | printSecrets | boolean | false | by default, secrets are replaced by hashes which are equal for same values using printHierarchy function. Set this true to print configuration values of keys containing secret or key. | | secretMatches | string[] | ['SECRET', 'KEY', 'SALT', 'PASSWORD'] | properties matching these expressions (flags added are /gi) are handled as secrets and will be hashed before printing |

JSON Schema

Enhanced validation

Custom validation keywords may be added to get detailed error messages for specific checks: https://medium.com/@moshfeu/test-json-schema-with-ajv-and-jest-c1d2984234c9

Dependencies

Multiple supported keywords exist in ajv to define dependencies.

Use cases

  • To apply NODE_ENV-specific defaults, use NODE_ENV.json-file in config folder
  • To apply global defaults, set default in schema file itself
  • To apply secrets, set values using .env file (never commit this file!)
  • To apply feature-flag conditions, see dependency keywords above.