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

unv

v0.3.10

Published

Universal application dev server and build tool

Downloads

73

Readme

unv

Build status Git tag NPM version Code style

Universal, javascript-only application dev server and build tool.

Installation

$ npm install unv

Overview

unv is not trying to be everything for everyone. It's designed to work very well with the way we bootstrap projects at Weo. If your projects are like ours, it'll be great. If not, look into something like budo which is less opinionated.

CLI

If you have a src/client.js or a lib/client.js (in that order), then you can just run:

unv dev

In your project's root. If you want more options, then...

Options

  • --port <port> - Port to listen on. Defaults to 3000.
  • --server <file> - Server entrypoint
  • --client <file> - Client entrypoint
  • --modules <dir> - Root module folder. E.g. src/. This folder will be added to the module resolution path, so that you can require from it directly. E.g. require('components/modal'), assuming your src folder contains a 'components' folder. This is of course in addition to node_modules. All of your transforms / babel plugins will run on these modules without issue (often there are problems with this if you try to use symlinks from node_modules).

client.js

Doesn't need to export anything - just your clientside entrypoint and the first thing that will run in the browser. Example:

import domready from '@f/domready'
import vdux from 'vdux/dom'

domready(() => vdux({
  app,
  middleware,
  reducer
}))

server.js

Your server.js file should export a single function of the form render(request, urls). urls.js is the path to your javascript bundle, and request is a node request object. Your render function may return any yieldable value (e.g. promise, string, thunk, generator, etc.) that resolves to the HTML of the page you want to render.

Example:

export default function *(req, urls) {
  const {state, html} = yield main(req)

  return `
    <html>
      <head>
        <script type='text/javascript'>
          window.__initialState__ = ${JSON.stringify(state)}
        </script>
        <script type='text/javascript' src='${urls.js}'></script>
      </head>
      <body>
        ${html}
      </body>
     </html>
     `
}

Hot reloading

Hot reloading is turned on by default in the dev server, and since everything is javascript, it's the only type of reloading you'll need (i.e. no livereload). To support server-side hot reloading, your server.js may export a replace method.

Here's an example replace function:

function replace () {
  invalidate(new RegExp('^' + path.resolve('./src')))
  main = require('./main').default
}

function invalidate (re) {
  forEach(remove, require.cache)

  function remove (val, key) {
    if (re.test(key)) {
      delete require.cache[key]
    }
  }
}

Client-side hot reloading works using the browserify-hmr plugin.

Assets (e.g. images)

In both your server-side and client-side code, you can just require/import any assets you may have and it will resolve to the url it's going to be served from. E.g.

import weo from './weo.png'
import element from 'vdux/element'

function render () {
  return <img src={weo} />
}

export default render

CSS

There is currently not a particular solution for css. Which means you're mostly limited to css-in-js solutions at the moment. At Weo, we use jss-simple.

Building for production

unv will also support building all of your assets and an asset map (similar to webpack's) for production, but that is still TBD.

ES6

All of your code (server and client) will be babel'd from the start. So no need for any server.babel.js or anything like that.

License

MIT