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

type-level-schema

v1.4.2

Published

Typescript typings for JSON schemas

Downloads

2

Readme

type-level-schema

Build Status Greenkeeper badge

This library's goal

This library tries to minimize the amount of duplication of runtime type assertions, and compile time interfaces. This library will generate the appropriate interfaces for JSON schema objects. This library will not ship a runtime JSON schema validator, there are many of these already and most are quite good.

Example: ajv

import { Schema, Schematize } from 'type-level-schema';
import * as ajv from 'ajv';

const validate = <S extends Schema>(schema: S, thing: any): thing is Schematize<S> => {
    return (new ajv()).validate(schema, thing) as boolean;
};

// this helper assures that the schema you are specifying is a valid schema using compile-time types
// it also helps eliminate TS type widening: 'object' as 'object', 'string' as 'string', etc.
const asSchema = <S extends Schema>(schema: S) => schema;

const schema = asSchema({
    type: 'object',
    parameters: {
        id: { type: 'string' },
        page: { type: 'number' },
    },
});

const getData = async () => {
    const fetchedData = await fetch('/some/api/call').then(data => data.json()) as any;

    if (validate(schema, fetchedData)) return schema;
    throw new Error('oops');
}

const x = await getData(); // => { id: string, page: number };

This library is tested using both ajv and jsonschema as these are two of the more popular JSON Schema validators. This library should work with any JSON Schema validator that adheres to the JSON Schema standard.

Why?

Typescript adds static type safety to the internals of javascript libraries. Unfortunately, because typescript cannot control the type and shape of data being sent into a well-typed system, type level bugs can still occur. One way to deal with this is checking types at runtime. For instance:

const doThing = (x: number, y: string) => {
    if (typeof x !== 'number') throw new Error('expected a number');
    return parseInt(y) + x;
};

This example checks types of variables passed in by some consumer of this code (who apparently isn't using typescript).

Another (perhaps more common) example is:

interface ApiData {
    id: string;
    page: number;
    nextUri: string;
    data: string[];
}
const getDataFromSomeoneElsesAPI = (): Promise<ApiData> => {
    return fetch('/some/api/call').then(data => data.json()) as any;
};

Let's just hope that someoneElsesApi doesn't decide to change their contracts..

A runtime solution could look like:

const schema = {
    type: 'object',
    parameters: {
        id: { type: 'string' },
        page: { type: 'number' },
    },
};

interface ApiData {
    id: string;
    page: number;
};

const getData = async (): Promise<ApiData> => {
    const fetchedData = await fetch('/some/api/call').then(data => data.json()) as any;

    if (jsonSchemaValidator(schema, fetchedData)) return fetchedData;
    throw new Error("Expected fetched data to match schema, but it didn't :(");
};

Unfortunately, here we are specifying the expected shape of the data twice. This means twice as many places to change our contract when the api call changes. Twice as much code. Twice as many places to screw up.