Giter Site home page Giter Site logo

insin / nwb Goto Github PK

View Code? Open in Web Editor NEW
5.6K 66.0 334.0 2.69 MB

A toolkit for React, Preact, Inferno & vanilla JS apps, React libraries and other npm modules for the web, with no configuration (until you need it)

License: Other

JavaScript 98.36% HTML 0.72% CSS 0.92%
toolkit react preact inferno react-component npm-module webpack babel karma javascript

nwb's Introduction

nwb

Linux Travis Windows Appveyor npm package Coveralls

nwb

nwb is a toolkit for:

A zero-config development setup is provided, but nwb also supports configuration and plugin modules which add extra functionality (e.g. Sass support), should you need them

Install

Installing globally provides an nwb command for quick development and working with projects.

npm install -g nwb

Note: if you're using npm 5 and getting an EACCES: permission denied error from nwb's PhantomJS dependency while installing globally, try passing an --unsafe-perm flag:

npm install -g --unsafe-perm nwb

To use nwb's tooling in a project, install it as a devDependency and use nwb commands in package.json "scripts":

npm install --save-dev nwb
{
  "scripts": {
    "start": "nwb serve-react-app",
    "build": "nwb build-react-app"
  }
}

Quick Development

For quick development with React, Inferno, Preact or vanilla JavaScript, use the nwb react, nwb inferno, nwb preact or nwb webcommands.

import React, {Component} from 'react'

export default class App extends Component {
  render() {
    return <h1>Hello world!</h1>
  }
}
$ nwb react run app.js
✔ Installing react and react-dom
Starting Webpack compilation...
Compiled successfully in 5033 ms.

The app is running at http://localhost:3000/
$ nwb react build app.js
✔ Building React app

File size after gzip:

  dist\app.cff417a3.js  46.72 KB

See Quick Development with nwb for a more detailed guide.

React Apps

Use nwb new react-app to create a React app skeleton, preconfigured with npm scripts which use nwb for development:

nwb new react-app my-app
cd my-app/
npm start

Open localhost:3000, start editing the code and changes will be hot-reloaded into the running app.

npm test will run the app's tests and npm run build will create a production build.

See Developing React Apps with nwb for a more detailed guide.

Preact Apps

Use nwb new preact-app to create a Preact app skeleton:

nwb new preact-app my-app

Inferno Apps

Use nwb new inferno-app to create an Inferno app skeleton:

nwb new inferno-app my-app

Vanilla JavaScript Apps

Use nwb new web-app to create a vanilla JavaScript app skeleton:

nwb new web-app my-app

React Components and Libraries

nwb new react-component my-component

cd my-component/

npm start will run a demo app you can use to develop your component or library against.

npm test will run the project's tests and npm run build will create ES5, ES modules and UMD builds for publishing to npm.

See Developing React Components and Libraries with nwb for a more detailed guide.

npm Modules for the Web

nwb new web-module my-module

cd my-module/

npm test will run the project's tests and npm run build will create ES5, ES modules and UMD builds for publishing to npm.

Why use nwb?

Get started quickly. Start developing from a single .js file or generate a project skeleton.

Covers the whole development cycle. Development tools, testing and production builds for projects work out of the box, no configuration required.

Flexible. While everything works out of the box, you can also use an optional configuration file to tweak things to your liking.

Manages key development dependencies and configuration for you. Check out an example of the effect using nwb had on the amount of devDependencies and configuration to be managed in a real project it was dropped into.

MIT Licensed

Cover image created by GeorgioWan

Operating system icons created with Icons8

nwb's People

Contributors

adamweeks avatar bafs avatar balazs4 avatar brentatkins avatar bwendt-mylo avatar dethariel avatar dlmr avatar dtinth avatar evnbr avatar fix-fix avatar freefony avatar georgiowan avatar grahamlyus avatar hanford avatar insin avatar jamrizzi avatar jihchi avatar kevinbon avatar loklaan avatar lukeed avatar marcelometal avatar michaelsbradleyjr avatar muhnad avatar ngyikp avatar ntwcklng avatar rrapiteanu avatar stephenwf avatar timomeh avatar totaldis avatar treshugart avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nwb's Issues

Test nwb commands by actually, y'know, running them

This seems obvious for the new command:

  • Determine the absolute path to lib/binnwb.js
  • Create a temp directory and process.chdir() to it
  • Run the command
  • Assert that the created directory layout looks right without getting too exact into specifics
    • Check that
  • Clean up

Should the server/test run stuff be done more like a smoke test?

Edit: research

0.1

I started to make loaders configurable in 0.0.x and ended up doing a complete rewrite, plus porting to ES6.

Templates and tooling for:

  • React apps
  • React components (React demo app, ES5 and UMD build published to npm)
  • web modules (run at least in a browser, ES5 and UMD build published to npm)

Using:

  • Babel 5
    • React hot loading via Express + webpack middleware
  • Webpack
    • default loader pipeline which can be tweaked by different builds and by users via config,
    • default plugin pipeline which can be tweaked by different builds
  • Karma
    • PhantomJS
    • configured for coverage on Travis
    • Hardcoded for use with Mocha initially, as I need to stop adding features for 0.1 NOW
      • Ditto for the tests in templates, which use Mocha and Expect

nwb.config.js in module root - default included/configured by templates

  • required - nwb will refuse to run module tools without it, as it positively identifies the module type, whereas we used to glob for directories and make assumptions.
  • configure Babel settings
  • tweak Webpack loader configuration
  • define new constants to be replaced by Webpack
  • configure UMD build (global variable and externals for peerDependencies)
  • UMD is optional via config, prompt when creating module
  • Vendor CSS bundle

CSS preprocessor plugins

Using this issue to track support for various CSS preprocessors via plugins and nwb functionality they depend on, or which needs to be added before a plugin can be implemented.

Use this issue to request more plugins..

The idea with CSS preprocessor plugins is that just installing one in your project sets up a default Webpack style loading pipeline, which you can then tweak using your nwb.config.js file.

Misc ideas

  • Investigate/configure rewire for tests
  • Enable running of the user's own lint setup - e.g. check for a lint script in npm run and run it, or let them configure something in the config file.
  • Offer a selection of Karma testing framework/assertion library options when running new and install and configure them for the user
  • Is there a clean way to extract the React-specific pieces out?
    • what if project types were implemented as plugins, registering
      • a project type for which they can handle or provide additional configuration for new, clean, build, serve and test commands
      • new top-level commands
  • Other plugin types?

Inject webpack assets instead of hardcoding them in the template

Investigate using inject: true to insert webpack assers before </body> - the current template hardcodes them, resulting in 404s for everything but app.js when running webpack on the server.

This should also preserve the correct ordering of dependencies, as html-webpack-plugin inserts entry assets last.

Functionality to extend nwb commands

Hey, great work on nwb @insin,

Is it possible to add custom commands via nwb.config.js into an app? Maybe if there was a way to specify what a custom command would call or do as some kind of extension/transformer. The reason I ask is because I'd love it there was some way of performing linting checks/fixes and a build where the output is minified. Also being able to specify a custom project template when using new and init would be great.

Allow test setup to be replaced?

I rely on Karma+Mocha+Chai+Phantom in my current test setup. Do you think it would make sense to allow the testing portion to be replaced with something else? Ideally I would push my setup to a package of its own and then feed it to nwb somehow (.nwb?).

Plugin API - CSS Preprocessors

How much magic do we really want here?

Thinking about CSS preprocessors, It would be nice if you could just install an nwb-sass, nwb-less etc. package which would hook these up with default pipelines for static and server builds like CSS currently has. So a bit of package.json scanning for those.

All they really need to provide is a unique name and test and loader config (absolute path to a dependency owned by the plugin). What if this was the entire nwb-sass plugin?

module.exports = {
  cssPreprocessor: {
    sass: {
      test: /\.scss$/,
      loader: require.resolve('sass-loader')
    }
  }
}

We could potentially use whatever hook we add for this to allow the user to configure and manage their own preprocessor dependencies.

Only use `process.exit()` in the bin script

Using process.exit() instead of throwing or calling back where appropriate makes it fiddly to test, and to test with coverage.

It's currently being used in:

src/cli.js
src/commands/build-umd.js
src/commands/new.js
src/commands/serve-react.js
src/commands/serve.js
src/createServeReactAppBuildConfig.js
src/createWebpackConfig.js
src/devServer.js
src/getUserConfig.js
src/webpackBuild.js

Add option to run server with custom IP

Add option to change the IP at the bottom of src/devServer.js.

Being localhost the page is inaccessible from network devices, changing it to 0.0.0.0 does the job.

nwb server error: use of const in strict mode

Followed the quick start, when I get to the nwb serve part I get this error:

nwb: error running serve:

/usr/local/lib/node_modules/nwb/node_modules/qs/lib/index.js:5
const Stringify = require('./stringify');
^^^^^
SyntaxError: Use of const in strict mode.
    at exports.runInThisContext (vm.js:73:16)
    at Module._compile (module.js:443:25)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.<anonymous> (/usr/local/lib/node_modules/nwb/lib/createWebpackConfig.js:43:11)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.<anonymous> (/usr/local/lib/node_modules/nwb/lib/createServeReactWebpackConfig.js:13:28)
    at Module._compile (module.js:460:26)

Code generators for React apps

React doesn't have built-in conventions for how you structure your apps, other than its components, which naturally define certain types of boundaries.

Despite that, any time you find yourself repeating the same thing over and over, you've effectively created a convention.

For example:

If you decided you wanted to try these conventions to quickly spin up an app, what if you could just generate new routes/route components which fit the pattern instead of having to manually create, copy and paste? (The webpack incantation for bundle splitting child routes could just be triggered by a flag, for one thing!).

There's also some boilerplate for which I always find myself referring back to documentation, official examples and previous projects, such as how to initially set up a store, middleware etc. in @gaearon's Redux with hot reloading, reducer bundle splitting and development tooling configured correctly. As much as I hate that code generation has the same problems as copy and paste after the initial convenience, if I could generate a known-good version of that boilerplate and perhaps even install the necessary dependencies in one fell swoop, it would remove a source of inertia in adding Redux to an app.


I'd also be interested in exploring a role for codemods - what if generators didn't leave you high and dry once you've generated - and especially after you've tweaked - the code, but could provide codemods which could update your dependencies and attempt to update the code to the latest version when libraries change?

Standalone serving and building of React apps

There's already an undocumented, untested serve-react command.

Also add a build-react command. (Naming? bundle-react?)

Both should take an entry module and attempt to serve or build a React app without requiring an nwb.config.js file to be present.

Babel 6

Dependencies

  • Publish development version of deduped-babel-presets to npm
  • Update all dependencies to their Babel 6 versions

nwb

  • Get nwb itself building and testing with Babel 6 using presets from deduped-babel-presets

User config

  • Validate that babel.stage is either 0-3 or falsy when provided
  • Warn if a babel.loose string is present in 0.12 config and treat it as its boolean equivalent
  • Support a babel.runtime flag or string to include the transform runtime plugin

Babel config generation

Generate Babel 6 config using deduped-babel-config presets based on build and user config

  • Support stage number user config as per Babel 5 and use it to choose presets.
  • Support loose as boolean user config to use an ES2015 -loose config from deduped-babel-presets
  • Support native boolean build config to to use an ES2015 -native config from deduped-babel-presets
  • Support presets list of strings build config to to use additional named presets from deduped-babel-presets
  • Support runtimeto use the runtime transform and choose which features to enable

Build config

  • Configure Babel build config for React development builds
  • Configure Babel build config for React production builds (taking --preact into account)
  • Enable the 'react' preset by default for module and UMD builds for JSX transforms when needed (hashtag YOLO)
  • Use generated Babel config with babel-loader when generating Webpack config
  • Update Karma config generation to use babel-polyfill

Other

  • Update tests
  • Update docs

(Was: Waiting for gaearon/babel-plugin-react-transform#50)

universal/isomorphic app support?

After reading most of the documentation I could not find any information about server sider rendering. Is this on the roadmap?
To me this would be a really valuable feature since it's probably the hardest part of the tooling.

Still a big thanks for your work so far! The react eco system will be much better of with a tool like this.

npm version

this project looks great, but the npm version is troublingly out of date. is there anything i can do to help you upgrade?

Log paths of created files

Check how easy this is to add to with copy-template-dir and create a PR

We don't want to grab a list of files in the output directory ourselves as we will be adding an nwb init command which can create files in existing dirs.

Add CONTRIBUTING.md to template projects

The current contents of template README.md files really belong in a CONTRIBUTING.md

Drop the instructions to install globally, as this isn't necessary for contributors due to nwb being in devDependencies

Always run tools in the user's current working directory

Currently, Karma tests are run in the context of nwb's install directory.

We should be able to import all plugins managed by nwb instead of using strings and having Karma import them, so changing the working directory shouldn't be necessary any more.

Benefits:

  • Less surprising for the user
  • Makes additional config easier - additional plugins could be specified as shorthand strings, as Babel should now be able to resolve and require plugins installed in the user's own project

0.8

Using issues for next release planning now, as Milestones are useless for tracking progress when working in the next branch.

  • #65 merge webpack.extra into webpack config (replaces #43 - support adding new Webpack plugins via user config)
  • #59 - replace npm-install-loader with npm-install-webpack-plugin
  • #56 - nwb.config.js should only be required for generic build commands which need .type
    • Document
  • #44 - make config more consistent
  • #41 - always run tools in the user's working directory
    • Update docs
  • #40 - move the current template project README.md contents to a CONTRIBUTING.md

Express middleware

Idea: with a locally-installed nwb have it take care of the details of creating webpack config and middleware for doing development hot reloading from your own Express server, so you don't have to mess about with proxying, and we don't have to make nwb's own dev server any more complicated.

Hypothetical usage:

app.use(require('nwb/express')(express, options))

...and nwb would do the rest.

Consistently use namespace objects in config - breaking change

Make this only take up one namespace slot in the config object.

Before - set umd to false to disable:

{
  umd: true,
  global: 'Blah',
  externals: {
    foo: 'Foo'
  }
}

After - omit umd or set it to 'false' to disable

{
  umd: {
    global: 'Blah',
    externals: {
      foo: 'Foo'
    }
  }
}

Technically a simple change, but it's made fiddly by copy-template-dir only supportting replacement of {{blah}} variables, so we might need to look for something else.

We'll keep backwards compatibility with the old format plus warning messages in 0.2 and remove it in the following release.

App build configs need a publicPath

nwb <= 0.7.x

Images required from JavaScript won't be resolved, otherwise.

(This also needs to be configurable for people serving apps from subdirectories)

Make config more consistent

As mentioned in #43, I was probably over-influenced by trying to keep the per-config item example code small when writing the initial Configuration docs.

Nest everything under appropriate props as per babel and karma config:

  • build config object
  • webpack config object

Speculative future full-fat config (including changes required to support #43):

var MyConventionResolver = {
  // ...
}

module.exports = function(deps) {
  type: 'react-component',

  babel: {
    loose: 'all',
    optional: ['runtime'],
    plugins: [require('babel-plugin-react-html-attrs')],
    stage: 0
  },

  webpack: {
    loaders: {
      css: {
        query: {
          modules: true
        }
      },
      install: {
        query: {
          cli: {
            saveExact: true
          }
        },
      },
      extra: [
        // ...
      ]
    },
    plugins: {
      define: {
        __VERSION__: JSON.stringify(require('./package.json').version)
      },
      extra: [
        new deps.webpack.ResolverPlugin([MyConventionResolver])
      ]
    }
  },

  karma: {
    tests: 'test/**/*-test.js',
    frameworks: [
      require('karma-tap')
    ]
  },

  build: {
    umd: true,
    global: 'FooComponent',
    externals: {
      'react': 'React'
    },
    jsNext: true
  }
}

Hopefully the need to manually require plugins in config can also be dealt with as part of #41

react-component generator not working

Hi,

Great work here so far - extremely useful for bringing a set of ember-cli-like conventions which is sorely needed in the React community IMO.

I am attempting to use nwb to create a higher-order react component. The problem is that when I generate a component using:

nwb new react-component my-component

I am asked about UMD and give it a global.

It creates the directory and installs dependencies.

the resulting directory looks like this:

.
├── README.md
├── node_modules
├── npm-debug.log
└── package.json

1 directory, 3 files

However, when i create an app with nwb, the structure is correct:

.
├── README.md
├── node_modules
├── nwb.config.js
├── package.json
├── public
├── src
└── tests

4 directories, 3 files

and with web-modules:

.
├── README.md
└── package.json

0 directories, 2 files

any idea what could be causing this?

Thanks!

Bad URLs from CSS built with default config

Trying a build with react-fa, it looks like CSS url() generation is expecting publicPath to be absolute, but the default config uses a relative path so we can deploy to a subdirectory or just open the .html file and have the app run.

Source map not working?

Are source maps meant to work out of the box? It doesn't seem to be the case here... In browser error reporting also has 404 links to source code, which might be related.

With this code:

import React from 'react'
import Icon from 'react-fa'

export default React.createClass({
  render() {
    foo(bar);
    return <div>
      <h2>Welcome to React!</h2>
      <Icon spin name="edge" />
    </div>
  }
})

I get this in the browser:

nwb_error_reporting

I would expect error reporting to point at my code rather than at the bundled code.

Babel runtime in dev (redux DockMonitor) - npm3

When using redux dev tools, I get the following error:

ERROR in ./~/react-dock/lib/index.js
Module not found: Error: Cannot resolve 'file' or 'directory' /Users/geowarin/dev/react/nwb-tests/test-app/node_modules/node_modules/babel-runtime/helpers/interop-require-default in /Users/geowarin/dev/react/nwb-tests/test-app/node_modules/react-dock/lib
 @ ./~/react-dock/lib/index.js 3:29-85

This path is strange: /node_modules/node_modules/babel-runtime.
The other thing is it cannot be reproduced when nwb is installed locally and linked with npm link.

My guess is that there is something wrong with this config.

Repro here:
https://travis-ci.org/geowarin/test-app/builds/99708029

Supporting both npm 2 and 3 looks like a chore.

Local install doesn't work with npm3

The assumptions being made about node_modules and .bin currently only work for npm2 when nwb is installed locally (e.g. for a Travis CI build)

Write an integration test for HMR config

Test that HMR is configured correctly:

  • Create a new React app and spawn nwb serve
  • Wait for the initial webpack build to finish
  • Connect a Node EventSource client to localhost:3000/__webpack_hmr
  • Change the contents of an app file
  • Assert that webpack rebuilds successfully from child process stdout
  • Assert whatever gets sent via EventSource for HMR changes

These seem to be the expected messages over the EventSource for a successful hot reload:

{"action":"building"}
{"action":"built","time":787,"hash":"2308f3431462588f6208","warnings":[],"errors":[],"modules":{...}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.