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

create-frontend-temporary

v0.2.0

Published

Create server-rendered universal JavaScript applications with no configuration

Downloads

2

Readme

CircleCI npm version npm dependencies npm downloads

Universal JavaScript applications are tough to setup. Either you buy into a framework like Next.js or react-server, fork a boilerplate, or set things up yourself.

Frontend comes with the "battery-pack included":

  • :fire: Universal Hot Module Replacement, so both the client and server update whenever you make edits. No annoying restarts necessary
  • Comes with your favorite ES6 JavaScript goodies
  • Comes with the same CSS setup as create-react-app
  • Works with React
  • Escape hatches for customization via .babelrc and frontend.config.js

Quick Start

npx create-frontend bootstrap my-app
cd my-app
yarn start

Then open http://localhost:3000/ to see your app. Your console should look like this:

That's it. You don't need to worry about setting up multiple webpack configs or other build tools. Just start editing src/App.js and go!

Below is a list of commands you will probably find useful.

yarn start

Runs the project in development mode.
You can view your application at http://localhost:3000

The page will reload if you make edits.

yarn build

Builds the app for production to the build folder.

The build is minified and the filenames include the hashes. Your app is ready to be deployed!

yarn start:prod

Runs the compiled app in production.

You can again view your application at http://localhost:3000

npm test or yarn test

Runs the test watcher (Jest) in an interactive mode. By default, runs tests related to files changed since the last commit.

rs

If your application is running, and you need to manually restart your server, you do not need to completely kill and rebundle your application. Instead you can just type rs and press enter in terminal.

Customization

Customizing Babel Config

Frontend comes with most of ES6 stuff you need. However, if you want to add your own babel transformations, just add a .babelrc file to the root of your project.

{
  "presets": [
    "stage-0"
   ],
   "plugins": [
     // additional plugins
   ]
}

A word of advice: the .babelrc file will replace the internal frontend babelrc template. You must include at the very minimum the default frontend/babel preset.

Extending Webpack

You can also extend the underlying webpack config. Create a file called frontend.config.js in your project's root.

// frontend.config.js

module.exports = {
  modify: (config, { target, dev }, webpack) => {
    // do something to config

    return config;
  },
};

CSS Modules

Frontend supports CSS Modules using Webpack's css-loader. Simply import your CSS file with the extension .module.css and Frontend will process the file using css-loader.

import React from 'react';
import styles from './style.module.css';

const Component = () => <div className={styles.className} />;

export default Component;

Environment Variables

Build-time Variables

The following environment variables are embedded during the build time.

  • process.env.PUBLIC_DIR: Path to the public directory.
  • process.env.ASSETS_MANIFEST: Path to a file containing compiled asset outputs
  • process.env.LOADABLE_MANIFEST: Path to a file containing compiled react-loadable outputs
  • process.env.REACT_BUNDLE_PATH: Relative path to where React will be bundled during development. Unless you are modifying the output path of your webpack config, you can safely ignore this. This path is used by react-error-overlay and webpack to power up the fancy runtime error iframe. For example, if you are using common chunks and an extra entry to create a vendor bundle with stuff like react, react-dom, react-router, etc. called vendor.js, and you've changed webpack's output to [name].js in development, you'd want to set this environment variable to /static/js/vendor.js. If you do not make this change, nothing bad will happen, you will simply not get the cool error overlay when there are runtime errors. You'll just see them in the console. Note: This does not impact production bundling.
  • process.env.VERBOSE: default is false, setting this to true will not clear the console when you make edits in development (useful for debugging).
  • process.env.PORT: default is 3000, unless changed
  • process.env.HOST: default is 0.0.0.0
  • process.env.NODE_ENV: 'development' or 'production'
  • process.env.BUILD_TARGET: either 'client' or 'server'
  • process.env.PUBLIC_PATH: Only in used in frontend build. You can alter the webpack.config.output.publicPath of the client assets (bundle, css, and images). This is useful if you plan to serve your assets from a CDN. Make sure to include a trailing slash (e.g. PUBLIC_PATH=https://cdn.example.com/). If you are using React and altering the public path, make sure to also include the crossorigin attribute on your <script> tag in src/server.jsx.
  • process.env.CLIENT_PUBLIC_PATH: The NODE_ENV=development build's BUILD_TARGET=client has a different PUBLIC_PATH than BUILD_TARGET=server. Default is http://${process.env.HOST}:${process.env.PORT + 1}/

You can create your own custom build-time environment variables. They must start with FRONTEND_. Any other variables except the ones listed above will be ignored to avoid accidentally exposing a private key on the machine that could have the same name. Changing any environment variables will require you to restart the development server if it is running.

These environment variables will be defined for you on process.env. For example, having an environment variable named SECRET_CODE will be exposed in your JS as process.env.SECRET_CODE.