0.0.1 • Published 4 years ago

ts-iptc-ninjs-type v0.0.1

Weekly downloads
-
License
MIT
Repository
github
Last release
4 years ago

IPTC NinJS V1.3 Type Definition

Typescript type definition of IPTCs NinJS V1.3 standard.

Usage

IptcNinjs Type

import { IptcNinjs } from 'ts-iptc-ninjs-type';

const typed: IptcNinjs = {
  "uri": "https://myuri.com/test/1"
};

The IPTC NinJS 1.3 schema allows for pattern properties as defined at the top level by: -

"^description_[a-zA-Z0-9_]+": {
  "title": "Description",
  "description": "A free-form textual description of the content of the item. (The string appended to description_ in the property name should reflect the format and/or the purpose of the text, separating the parts with _). nar:description",
  "type": "string"
},
"^body_[a-zA-Z0-9_]+": {
  "title": "Body",
  "description": "The textual content of the news object. (The string appended to body_ in the property name should reflect the format and/or the purpose of the text, separating the parts with _). nar:inlineData or nar:inlineXML",
  "type": "string"
},
"^headline_[a-zA-Z0-9_]+": {
  "title": "Extra headlines",
  "description": "Additional headlines or strings of that type can be handled here. This is not replacing the main headline-property in ninjs. (The string appended to headline_ in the property name should reflect the format and/or the purpose of the text, separating the parts with _) nar:headline with roles issue #13. (Added in 1.3)",
  "type": "string"
}

Also within 'place': -

"^geometry_[a-zA-Z0-9_]+": {
  "description": "An object holding geo data of this place. Could be of any relevant geo data JSON object definition.",
  "type": "object"
}

Without being opinionated on the patterns users of the IptcNinjs interface will choose to use these partially defined pattern properties could not be represented in the interface.

To use these it is recommended you extend the interface to your needs e.g.

import { IptcNinjs } from 'ts-iptc-ninjs-type';

interface Ninjs extends IptcNinjs {
  description_html?: string,
  description_text?: string,
}
import { IptcNinjs, NinjsLink } from 'ts-iptc-ninjs-type';

interface NinjsPlace extends NinjsLink {
  geometry_example?: Record<string, unknown>;
}

interface Ninjs extends IptcNinjs {
  place?: NinjsPlace[]
}

Validating JSON

Included is a validator which can be used to ensure JSON conforms to the IPTC Ninjs 1.3 schema it can be used as follows: -

import { IptcNinjs, IptcNinjsValidator } from 'ts-iptc-ninjs-type';

const validator: IptcNinjsValidator = new IptcNinjsValidator();
const typed: IptcNinjs = {
  "uri": "https://myuri.com/test/1"
};
const valid: boolean = validator.validate(typed);

Installation

You need node.js installed globally to run the tests. We recommend you manage your Node versions with nvm.

nvmrc

The use of nvm allows for easier management of the complexities of Node and npm versioning. To use nvm, run:

nvm use

This will select the appropriate version of the Node installed on your machine upon the .nvmrc file.

Login

Ensure you're authenticated with the target NPM repository

Dependencies

To install the dependencies specified by package-lock.json:

npm ci

Testing

Unit Tests

Tests are run using the jest framework and include a coverage check as default.

Run unit tests:

npm run test

Lint (code)

A default TypeScript style lint (tslint.json) has been included in this build. To ensure that the TS files conform to the lint, run:

npm run lint

Lint (package)

There is also a package.json linter (rules specified in .npmpackagejsonlintrc.json) to verify the contents of that file which can be run by:

npm run lint:package

Sanity Testing

There is an aggregate script provided for running all of the check and ensuring correct building of the final library:

npm run test:sanity

Semantic Release

To ensure consistent releases and versioning that adheres to semver we use semantic release.

Commit style

It is recommended for clarity that the ticket reference is included in the commit message body, the format should be as follows:

fix|feat|perf(<short_feature_name>): <ticket> - <description_of_change>

Here is an example of the release type that will be done based on a commit messages.

Commit messageRelease type
fix(logging): TICKET-1234 - Additional loggingPatch Release
feat(publish-endpoint): TICKET-2345 - Addition of the /publish endpoint to the APIMinor Feature Release
perf(event-model): TICKET-3456 - Event model updateBREAKING CHANGE: The time attribute has been removed.Major Breaking Release

Tech

0.0.1

4 years ago