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

@comtstore/lib0

v0.2.82

Published

> Monorepo of isomorphic utility functions

Downloads

1

Readme

Lib0 Build Status

Monorepo of isomorphic utility functions

This library is meant to replace all global JavaScript functions with isomorphic module imports. Additionally, it implements several performance-oriented utility modules. Most noteworthy are the binary encoding/decoding modules [lib0/encoding] / [lib0/decoding], the randomized testing framework [lib0/testing], the fast Pseudo Random Number Generator [lib0/PRNG], the small socket.io alternative [lib0/websocket], and the logging module [lib0/logging] that allows colorized logging in all environments. Lib0 has only one dependency, which is also from the author of lib0. If lib0 is transpiled with rollup or webpack, very little code is produced because of the way that it is written. All exports are pure and are removed by transpilers that support dead code elimination. Here is an example of how dead code elemination and mangling optimizes code from lib0:

// How the code is optimized by transpilers:

// lib0/json.js
export const stringify = JSON.stringify
export const parse = JSON.parse

// index.js
import * as json from 'lib0/json'
export const f = (arg1, arg2) => json.stringify(arg1) + json.stringify(arg2)

// compiled with rollup and uglifyjs:
const s=JSON.stringify,f=(a,b)=>s(a)+s(b)
export {f}

Performance resources

Each function in this library is tested thoroughly and is not deoptimized by v8 (except some logging and comparison functions that can't be implemented without deoptimizations). This library implements its own test suite that is designed for randomized testing and inspecting performance issues.

  • node --trace-deopt and node --trace-opt
  • https://youtu.be/IFWulQnM5E0 Good intro video
  • https://github.com/thlorenz/v8-perf
  • https://github.com/thlorenz/deoptigate - A great tool for investigating deoptimizations
  • https://github.com/vhf/v8-bailout-reasons - Description of some deopt messages

Code style

The code style might be a bit different from what you are used to. Stay open. Most of the design choices have been thought through. The purpose of this code style is to create code that is optimized by the compiler and that results in small code bundles when used with common module bundlers. Keep that in mind when reading the library.

  • No polymorphism!
  • Modules should only export pure functions and constants. This way the module bundler can eliminate dead code. The statement const x = someCondition ? A : B cannot be eleminated, because it is tied to a condition.
  • Use Classes for structuring data. Classes are well supported by jsdoc and are immediately optimized by the compiler. I.e. prefer class Coord { constructor (x, y) { this.x = x; this.y = y} } instead of { x: x, y: y }, because the compiler needs to be assured that the order of properties does not change. { y: y, x: x } has a different hidden class than { x: x, y: y }, which will lead to code deoptimizations if their use is alternated.
  • The user of your module should never create data objects with the new keyword. Prefer exporting factory functions like const createCoordinate = (x, y) => new Coord(x, y).
  • The use of class methods is discouraged, because method names can't be mangled or removed by dead code elimination.
  • The only acceptable use of methods is when two objects implement functionality differently. E.g. class Duck { eat () { swallow() } } and class Cow { eat () { chew() } } have the same signature, but implement it differently.
  • Prefer const variable declarations. Use let only in loops. const always leads to easier code.
  • Keep the potential execution stack small and compartmentalized. Nobody wants to debug spaghetti code.
  • Give proper names to your functions and ask yourself if you would know what the function does if you saw it in the execution stack.
  • Avoid recursion. There is a stack limit in most browsers and not every recursive function is optimized by the compiler.
  • Semicolons are superfluous. Lint with https://standardjs.com/

Using lib0

lib0 contains isomorphic modules that work in nodejs, the browser, and other environments. It exports modules as the commonjs and the new esm module format.

If possible,

ESM module

import module from 'lib0/[module]' // automatically resolves to lib0/[module].js

CommonJS

require('lib0/[module]') // automatically resolves to lib0/dist/[module].cjs

Manual

Automatically resolving to commonjs and esm modules is implemented using conditional exports which is available in node>=v12. If support for older versions is required, then it is recommended to define the location of the module manually:

import module from 'lib0/[module].js'
// require('lib0/dist/[module].cjs')

Modules