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

huzma

v0.6.2

Published

A manifest format for browser-based package managers

Downloads

7

Readme

بسم الله الرحمن الرحيم

Huzma 📦

A manifest format for browser-based package managers

Huzma (the Arabic word for package, pronounced like this, spelt in Arabic حزمة) is a manifest format for browser-based package managers. This library is a Javascript implementation of the Huzma manifest format which includes:

Originally made to import game mods into the Zakhaarif Launcher, this format takes inspiration from Node's package.json and Rust's cargo.toml.

Installation

npm i huzma

Specification

A huzma is a json file that has the file extension .huzma.json and includes these keys:

⚠️ Required

  • schema: an integer value of 1 or 2, indicating which huzma version is used.

  • name: a string naming package.

  • version: a vaild semver (semantic version) string, indicating the version of package. Implementation provided by small-semver package.

✅ Optional

  • files: an array of strings or objects indicating files that should be cached on disk if possible (via Cache API, IndexedDB, etc.). Objects must include a string value at name field and an optional integer value at bytes field and invalidation (string) at invalidation field.

    If a string value is provided it indicates the relative url of a file. If an object value is provided the name field repersents the relative url of a file, the invalidation field repersents how file should be diffed on package update, and the bytes field repersents uncompressed size of file in bytes.

    All File urls must be relative to huzma manifest and cannot be an absolute url or start with ../.

    Example:

    {
        "files": [
            "index.js",
            "./index.js",
            "assets/cat.png",
            {"name": "assets/doggo.png"},
            {"name": "styles/style.css", "bytes": 1234},
            {
                "name": "multi-thread.wasm", 
                "invalidation": "purge"
            },
            {
                "name": "config.json", 
                "invalidation": "url-diff",
                "bytes": 10540
            }
        ]
    }
  • entry: a url relative to huzma manifest that denotes an entry script (cannot be an absolute url or start with ../.). This communicates to package managers which file to import in order to execute code included in package.

  • invalidation: specify the default invalidation strategy for all files mentioned in files field.

  • description: a string that describes package.

  • authors: an array of objects repersenting project maintainers / main contributors. Object must include a string value at name field, and optionally can provide an email value at email field and url (absolute) for at url field.

    Example:

    {
        "authors": [
            {"name": "moomoolive"}, 
            {
                "name": "milk_farmer", 
                "email": "[email protected]"
            }, 
            {
                "name": "pure_lactose", 
                "email": "[email protected]", 
                "url": "https://whatsinyourmilk.milk"
            }
        ]
    }
  • logoUrl: a relative or absolute url to a picture that repersents package. Examples: https://yo-mamas.house/logo.png, ./silly-logo.jpg, etc.

  • keywords: an array of string tags that describe package. Examples: penguins, kitties, html-parser, etc.

  • license: a string denoting license granted to package user. Examples: MIT, GPL-3, Apache-2, My-Own-Cool-License, etc.

  • repo: an object representing package's code repository, with an optional string value at type field and url at url field.

    Example:

    {
        "repo": {
            "type": "git", 
            "url": "https://github.com/moomoolive/huzma"
        }
    }
  • homepageUrl: absolute url to package website. Example: https://www.nexusmods.com/my-amazing-mod-homepage

  • permissions: an array of strings or objects with a string value at key field and an array of strings at value field. A string value (i.e "permission") is equivalent to an object with a string value at key field and an empty array at value field (i.e { "key": "permission", "value": [] }).

    It is up to package managers to implement a concrete set of permissions.

    Example:

    {
        "permissions": [
            "permission1",
            {"key": "permission2", "value": []},
            {"key": "permission3", "value": ["value1"]},
            {"key": "permission3", "value": ["value1", "value2"]},
        ]
    }
  • metadata: an object of arbitrary key & value pairs, where values are strings. Denotes specific information a particular package manager may want to know about package. Works similar to http headers.

    Example:

    {
        "metadata": {
            "is-extension": "true",
            "pkg-manager-x-key": "key-exists",
            "created": "100003231414",
            "updated": "100003431414"
        }
    }

Invalidations

If a new version of a package is released, package managers will need to update the cached files of said package. Providing an invalidation strategy for a file(s) hints to package managers how to cache files.

Here are a list of strategies that may be provided:

  • url-diff: file should only be cached if file with same url does not exist in package manager cache. Otherwise, file should not be cached.

  • purge: file should be recached on every new package version, regardless if a file with same url exists in package manager cache. By default the entry file of a huzma manifest uses this strategy if it is found in files.

  • default: let package manager decide.

Command Line Tools

This package comes bundled with cli commands to help create huzem (plural for huzma). All commands can be programmatically invoked from as well. Package must be installed to invoke commands.

npx huzma-init

Initialize a huzma config file - a configuration file which is used by other commands in this package.

Options:

  • path: a path where huzma config file should be created, must end with js or mjs extension. Defaults to huzma.config.mjs.

    CLI:

    npx huzma-init --path huzma.config.mjs

    JS:

    import {initHuzma} from "huzma/dist/cli.js"
    
    await initHuzma({path: "huzma.config.mjs"})
  • template: available templates include zakhaarif. Defaults to empty string.

    CLI:

    npx huzma-init --template zakhaarif

    JS:

    import {initHuzma} from "huzma/dist/cli.js"
    
    await initHuzma({template: "zakhaarif"})

npx huzma-create

Create a huzma manifest.

Options:

  • buildDir: ⚠️ required, directory that includes all package files.

    CLI:

    npx huzma-create --buildDir dist

    JS:

    import {createHuzma} from "huzma/dist/cli.js"
    
    await createHuzma({buildDir: "dist"})
  • outFile: the full path with the generated huzma manifest should be written to. Path must end with .huzma.json. Defaults to buildDir + default.huzma.json.

    CLI:

    npx huzma-create --outFile dist/default.huzma.json

    js:

    import {createHuzma} from "huzma/dist/cli.js"
    
    await createHuzma({outFile: "dist/default.huzma.json"})
  • configFileName: path to huzma config file, path must end with js or mjs. Can be generated via npx huzma-init command. Defaults to huzma.config.mjs

    CLI:

    npx huzma-create --configFileName huzma.config.mjs

    JS:

    import {createHuzma} from "huzma/dist/cli.js"
    
    await createHuzma({configFileName: "huzma.config.mjs"})
  • packageJsonPath: Path to package json from which to auto-fill missing values from. See disablePackageJsonFill for more details. Defaults to package.json

    CLI:

    npx huzma-create --packageJsonPath package.json

    JS:

    import {createHuzma} from "huzma/dist/cli.js"
    
    await createHuzma({packageJsonPath: "package.json"})
  • disablePackageJsonFill: Whether missing values not found in config file & inline config should be autofilled from package json. Values in package json are given a lower precedent than values found in config file or inline config. Setting flag disables auto-fill. To set path of package json set the packageJsonPath argument. Values that can be auto-filled from package.json include:

    • name
    • version
    • description
    • keywords
    • license
    • repository: maps to huzma's repo field.
    • contributors: maps to huzma's authors field.
    • homepage: maps to huzma's homepageUrl field.

    CLI:

    npx huzma-create --disablePackageJsonFill

    JS:

    import {createHuzma} from "huzma/dist/cli.js"
    
    await createHuzma({disablePackageJsonFill: true})
  • inlineConfigFile: provide an inline config, which takes precedent over config file. Defaults to null. Cannot be used from cli.

    JS:

    import {createHuzma} from "huzma/dist/cli.js"
    
    await createHuzma({
        inlineConfigFile: {
            name: "my-huzma",
            version: "0.1.0"
            // ...rest of config
        }
    })