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

urql-docs

v6.4.1

Published

Documentation site for urql

Downloads

162

Readme

Urql documentation site

Build Status

Now built with react-static!

Getting Started

To install and run the docs site locally:

yarn install
yarn start

Note that paths in local development are based on a root of "/" but be careful when defining relative and absolute paths inline or doing url parsing, as the production output root will be "open-source/urql."

Want to see if you're ready to :shipit:?

To build the staging build output and serve it with the canonical path it'll have when built as a lander for formidable.com:

yarn stage
yarn serve

This step is important for validating that both the basePath used by the static HTML output and the basename used by the client-side router are working as expected. This is also where you'll want to validate that there are no hardcoded, inlined, or malformed asset paths that worked locally but will not resolve correctly in production!

Ready to Publish?

To publish to NPM run

This package must be published with [email protected]

npm version <newversion | major | minor | patch> (see Versioning notes below)
git push origin master && git push --tags
npm publish

Ready to Deploy?

OSS landers are deployed by the formidable.com package, see DEPLOYMENT.md or lib/actions.js there for how the build output is consumed.

Tips for developing

  • Almost all of your code will be executed in two contexts, first in node for server-side rendering and static html generation, then client-side as a PWA. In addition to writing node-safe code, this also means that it's necessary to validate that both the static html and and the PWA are working as expected.

  • In addition to two execution contexts, there are three stages: development, staging, and production. yarn start uses a local dev server with live reload that takes about one second to rebuild. This is a good choice for most local development, but it's important to keep in mind that the development server does not build the static html. For that, you will want to use yarn stage && yarn serve. The yarn build command is used by formidable.com within its build script that moves the output of this lander into the correct location within the overall site output.

  • When debugging an issue with the static html output, don't be shy about cracking open the dist folder and looking at the output!

  • When debugging an issue with the PWA or SSR-PWA coordination, consider using yarn stage-debug -- this builds the staging output without minification/uglification and propagates warnings/errors.

  • We have seen errors related to minification, uglification, and codesplitting before, please do not treat the debug build or the local dev server as 1:1 with production output!

Tips for getting the most out of react-static and webpack documentation and tooling

  • We are on react-static v5 due to blocking stability issues with v6, which means...

    • You'll want to make sure that when you refer to the docs you're in the v5 branch.

    • When you install the react-static CLI tool globally, you'll want to use the v5 version (npm install -g react-static@^5.9.12) which currently has a wider selection of working templates that can be very useful as executable canonical references.

    • If you're looking for the client-side router documentation for react-static to see how to implement a certain behavior, the best place to start is in the react-router docs, which react-static v5 uses under the hood. There are a few additional react-static specific properties for Router, Routes, and Link but if you need something from the routing that doesn't seem to covered in the react-static api, the react-router docs are pretty likely to have you covered.

    • You'll ~~want~~ need to use Webpack 3 plugins. Webpack has an interesting approach to documenting old versions. The existing documentation is broadly usable but you may want to familiarize yourself with this introductory v3 to v4 migration guide and the relevant react-static docs

    • Interestingly, some webpack v4 loaders still work with v3, while some webpack v3 loaders don't work with webpack v3. Version-twiddling or using a different loader for reasons that are unclear may be required. When tweaking webpack, it's extra-important to validate both PWA and static html output and clear out cached files.

Using this project as a template:

This lander is designed to be easily re-used as a template for other projects.

What to change:

  • Docs Content: markdown content lives in src/content/docs. Any markdown files placed here will be rendered as separate pages, and header tags will be rendered into a hierarchical sidebar. (Please make sure header tags do not include any special symbols as they will be used to create anchor tags and hashes)
  • Main page content
    • src/screens/home/_content.js includes section titles, descriptions, and assets urls
    • src/screens/home/hero.js
  • Constants: client and static constants live in src/constants.js and static-config-parts/constants.js respectively
  • Assets: logos, sidebar svgs and favicons (TODO: These are all very similar svgs, and could some day live in a separate repo, and take props like color, name etc)