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

infinity-fbjs

v1.0.1

Published

A collection of utility libraries used by other Facebook JS projects

Downloads

3

Readme

FBJS

Why fork

  • fix scroll position detect with perfect scroll bar

Purpose

To make it easier for Facebook to share and consume our own JavaScript. Primarily this will allow us to ship code without worrying too much about where it lives, keeping with the spirit of @providesModule but working in the broader JavaScript ecosystem.

Note: If you are consuming the code here and you are not also a Facebook project, be prepared for a bad time. APIs may appear or disappear and we may not follow semver strictly, though we will do our best to. This library is being published with our use cases in mind and is not necessarily meant to be consumed by the broader public. In order for us to move fast and ship projects like React and Relay, we've made the decision to not support everybody. We probably won't take your feature requests unless they align with our needs. There will be overlap in functionality here and in other open source projects.

Usage

Any @providesModule modules that are used by your project should be added to src/. They will be built and added to module-map.json. This file will contain a map from @providesModule name to what will be published as fbjs. The module-map.json file can then be consumed in your own project, along with the rewrite-modules Babel plugin (which we'll publish with this), to rewrite requires in your own project. Then, just make sure fbjs is a dependency in your package.json and your package will consume the shared code.

// Before transform
const emptyFunction = require('emptyFunction');
// After transform
const emptyFunction = require('fbjs/lib/emptyFunction');

See React for an example of this. Coming soon!

Building

It's as easy as just running gulp. This assumes you've also done npm install -g gulp.

gulp

Alternatively npm run build will also work.

Layout

Right now these packages represent a subset of packages that we use internally at Facebook. Mostly these are support libraries used when shipping larger libraries, like React and Relay, or products. Each of these packages is in its own directory under src/.

Process

Since we use @providesModule, we need to rewrite requires to be relative. Thanks to @providesModule requiring global uniqueness, we can do this easily. Eventually we'll try to make this part of the process go away by making more projects use CommonJS.

TODO

  • Flow: Ideally we'd ship our original files with type annotations, however that's not doable right now. We have a couple options:
    • Make sure our transpilation step converts inline type annotations to the comment format.
    • Make our build process also build Flow interface files which we can ship to npm.
  • Split into multiple packages. This will be better for more concise versioning, otherwise we'll likely just be shipping lots of major versions.