Commit 9e79afe7 authored by Peter East's avatar Peter East

Merge branch 'add-typescript' into 'master'

Add typescript

Start adding some typescript to this packages

See merge request !11
parents 475f0987 05dd758f
Pipeline #13225 passed with stage
in 1 minute and 18 seconds
node_modules/
cache:
key: "$CI_COMMIT_REF_SLUG"
paths:
- node_modules/
lint_typescript:
image: node:10-alpine
script: "yarn && yarn lint"
build_typescript:
image: node:10-alpine
script: "yarn && yarn build"
# Preface:
# PubSweet Types
- This is a view model created through discussion in the PubSweet meeting in July 2018.
- These models do not use Collections and Fragments, instead they are standalone models in separate tables.
- JATS is used as a vocabulary and a source of data types, wherever appropriate.
- All models have 'created' and 'updated' dates (with the exception of AuditLog, which does not have an `updated` date)
- All models have an 'id' UUID
- Dates are ISO-8601 strings, as PostgreSQL recommends this as date input, JATS allows it, and GraphQL can handle it.
Abstractions of types and interfaces for shared PubSweet components.
[Shared data model schema](schema.graphql)
## Purpose
The aim is to share a common set of types and interfaces between different publisher's implementations.
The idea is to mandate all PubSweet components to be shared will need to define the types and interfaces within this module. (This does not rule out breaking down this module later if the need arises).
## Background
One of the principle aims of the PubSweet community is to maximize reuse.
Often times this is difficult to do on a **code-level** as different organizations have different requirements
meaning code can become opinionated reducing its suitability for sharing.
In the past the shared-data-model was envisaged as the common interface between publishers.
However, each publisher has extended this model and sharing data structure is not conducive to
any publisher wishing to adopt a DDD approach, or needing an alternative approach to storing data.
The solution proposed is to introduce reuse at the **component-level**.
Across certain publishers independently, there has been an adoption of an architecture that uses [microservices](https://martinfowler.com/microservices/) or an approach using [Layers, Onions, Ports, Adapters: it's all the same](https://blog.ploeh.dk/2013/12/03/layers-onions-ports-adapters-its-all-the-same/).
Such an approach will create opportunities for reuse on the server-side beyond that of `pubsweet-server`
extending to any other microservice used, for example, @hindawi/queue-service.
Additionally, an alternative web-framework could be used other than `pubsweet-server` itself.
This allows publishers to build using their own needs for infrastructure while concentrating on sharing components
that handle the publishing domain in an abstract way.
This is seen as a way to increase reuse and diversity within the PubSweet community.
## Documentation
> You can generate documentation by running `yarn doc`, which will put HTML docs into the `doc/` folder
{
"name": "@pubsweet/types",
"version": "1.0.0",
"description": "",
"main": "dist/index.js",
"scripts": {
"build": "tsc --build tsconfig.json",
"lint": "tslint --project tsconfig.json"
},
"repository": {
"type": "git",
"url": "https://gitlab.coko.foundation/pubsweet/types"
},
"author": "",
"license": "ISC",
"dependencies": {
"funfix": "^7.0.1",
"pino": "^5.13.2",
"uuid": "^3.3.3"
},
"devDependencies": {
"@types/jest": "^24.0.18",
"jest": "^24.9.0",
"pino-pretty": "^3.2.1",
"tslint": "^5.20.0",
"typescript": "^3.5.3"
}
}
/**
* # Core types
* Share interfaces that exist in both domain and infrastructure concepts
*/
// tslint:disable-next-line
export interface Core {}
/**
* This is the lowest common denominator across all entities in PubSweet
*/
export interface IObject {
id: string;
created: Date;
}
// tslint:disable-next-line
export interface IAction {
}
/**
* Not everything is updatable
*/
export interface IUpdatable extends IObject {
updated?: Date;
}
export interface IDeletable extends IObject {
deleted?: Date;
}
export interface IMutable extends IUpdatable, IDeletable {}
export interface IActor extends IObject {
kind: 'user' | 'admin' | 'system';
actor_id: string;
}
export interface IOwnable extends IObject {
owner: IActor; // Need to define some kind of user interface
}
// Some things can have teams assigned to them
/**
* Denotes a collection of users
*/
export interface IAssignable {
assignees: IActor[];
}
/**
* Used to group comments/reviews/notes on a Submission
*
* Questions:
* - Is IFeedback an action or is it a Object?
*/
export interface IFeedback extends IOwnable, IObject {
content: string;
}
import { IAssignable, IActor, IObject, IMutable, IOwnable } from './abstract';
/**
* This is for domain types.
*
* This module is for interfaces and types that directly relate to the publishing domain.
* For example `ISubmittable` is a domain type, because it relates to a domain action that can be
* taken on a domain entity.
*/
// tslint:disable-next-line
export interface Domain {}
interface Organisation extends IMutable {
name: string;
journals: Journal[];
}
interface Journal extends IMutable {
journalTitle: string;
manuscripts: Submission[];
publisherName: string;
}
interface Submission extends IMutable {
manuscriptVersions: never;
files: File[];
teams: Team[];
reviews: Review[];
status: string;
formState: string;
decision: string;
title: string;
articleType: string;
articleIds: string;
abstract: string;
subjects: string;
history: Date[];
publicationDates: Date[];
notes: Note[];
}
interface Note extends IMutable {
notesType: string;
content: string;
}
interface File extends IMutable {
type: string;
label: string;
filename: string;
url: string;
mimeType: string;
size: number;
}
interface Review extends IMutable, IOwnable {
// wip
comments: unknown[];
reccomendation: string;
open: boolean;
}
interface Team extends IMutable, IAssignable {
members: TeamMember[]; // teamMember
role: string;
object: IObject;
objectType: string;
}
interface TeamMember {
user: IActor;
status: string;
alias: Alias; // Alias;
}
interface Alias extends PureIdentity {
name: string;
}
export interface LocalIdentifier {
name: string;
}
export interface ExternalIdentifier {
identifier: string;
type: string;
}
export interface PureIdentity extends IObject, IMutable {
email: string;
aff: string; // JATS <aff>
}
export interface LocalIdentity extends PureIdentity, LocalIdentifier {}
export interface ExternalIdentity extends PureIdentity, ExternalIdentifier {}
// Abstract types
// NO IMPLEMENTATION CODE ALLOWED!!
{
"extends": "./tsconfig.json",
"exclude": ["node_modules", "test", "dist", "**/*spec.ts"]
}
{
"compilerOptions": {
"module": "commonjs",
"declaration": true,
"removeComments": true,
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"target": "es6",
"sourceMap": true,
"outDir": "./dist",
"baseUrl": "./src",
"incremental": true,
"strictNullChecks": true
},
"exclude": ["node_modules"],
"include": ["src/**/*.ts"]
}
{
"defaultSeverity": "error",
"extends": ["tslint:recommended"],
"jsRules": {
"no-unused-expression": true
},
"rules": {
"quotemark": [true, "single"],
"member-access": [false],
"ordered-imports": [false],
"max-line-length": [true, 150],
"member-ordering": [false],
"interface-name": [false],
"arrow-parens": false,
"object-literal-sort-keys": false,
"no-any": true
},
"rulesDirectory": []
}
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment