🐦 Modern JavaScript Development Ecosystem
JavaScript
Latest commit 9165471 Feb 13, 2017 @dlmr dlmr committed on GitHub Merge pull request #160 from kjarmicki/master
Make template package.json optional
Permalink
Failed to load latest commit information.
bin CLI now use the provided --directory & fixed a problem with CLI errors Oct 17, 2016
converters Refactored the projects structure Jun 21, 2016
docs Corrected example of isString Feb 6, 2017
log Fixed export path for alias export of log default Jun 22, 2016
runtime Adds a convenient way to register the runtime with default options Aug 8, 2016
scripts Updated code to work with new ESLint rules Aug 8, 2016
src Make template package.json optional Feb 10, 2017
test This changes the opt-out character from _ to # Nov 16, 2016
validators Update readme, package name and docs for cli move Jan 5, 2016
.babelrc Updates how the tests and the coverage are generated Aug 16, 2016
.codeclimate.yml Ignore coverage. Correct link. Ignore jsx. Nov 27, 2015
.editorconfig Fixed typo in .editorconfig Nov 26, 2015
.eslintignore Cleaned up the tests and added some new ones + fixed issue with toObject Aug 16, 2016
.eslintrc Updated template system to be more flexible and better overall Sep 8, 2016
.gitignore Updated .gitignore to ignore .nyc_output Aug 16, 2016
.istanbul.yml Moved out the bin script to work better with postinstall Jan 14, 2016
.travis.yml Removed automatic deploy from Travis since we want more control over it Sep 20, 2016
LICENSE Updated license to 2016 Jan 6, 2016
README.md Made it clear that we recommend installing next Dec 6, 2016
appveyor.yml Removed npm test from test_script since we already test on npm install Sep 2, 2016
esdoc.json Updated and added documentation to the code Jan 5, 2016
package.json 1.0.0-rc.17 Feb 6, 2017
roc-new.gif Improved main README. Fixed links to outdated packages. Apr 8, 2016
roc.png Add logo file Mar 17, 2016

README.md

Roc

logo

Build JavaScript projects easily using modern libraries.

Quickly create products powered by libraries like Koa, React and Redux ready for deployment in production with minimal additional setup. Tools like Webpack and Babel power the build process.

Maintained and used in production by teams within Schibsted.

stability rc roc build status Coverage Status Code Climate Dependency Status
Currently supports Linux and OS X using Node4+ and npm3

roc@next

Use npm install -g roc@next to test the latest version.

Roc provides

  • A way to eliminate boilerplate code within your projects
  • Command Line Interface (CLI) for creating and managing your project
  • Consistent configuration and runtime management
  • Minimized complexity within projects by combining powerful modules together
  • Best in class developer tools ready to be used instantly

All of this is provided by a flexible extension system, and several extensions are available today.

Examples of what can be done today

  • Production ready React applications
  • Generic server applications
  • Generic web applications
  • JavaScript modules ready for npm and browser

More will be possible in the future and creating your own extension is easy.

Creating a React application with Roc

See here for an article that explains the following in more detail.

$ npm install -g roc@next
$ roc new react-app web-app-react
$ cd react-app && roc dev

install animation

This will:

  • Install Roc
  • Create a project that uses React and Redux
  • Start the project in development mode

Production ready

To build and run in production just use:

$ roc build
$ roc start

Where to go from here

A very common use-case is to make modifications to your roc.config.js. To get a better understanding of all the possible options in the package use the roc list-settings command or --help for a specific command.

Not a boilerplate!

Roc uses templates to initialize new projects. Templates are very thin skeletons that depend on Roc extensions that manage the typical boilerplate. Meaning only your own code will leave a significant footprint in your project. This allows you to maintain a very clean separation of concerns as your projects evolve.

Official Roc extensions are semantically versioned and will include changelogs compiling change summaries, making upgrade paths much simpler across your projects.

Is this not Yeoman?

No.

At first sight it might seem that Roc is similar to Yeoman but they do not address the same problem. Yeoman scaffolds a project for you based on a generator that might ask you some questions about how you want to setup your project. However after that has been performed there is no easy way to update the project if a new version of the generator is created. Yeoman will additionally add a lot of code into your project which is basically boilerplate code, that you will seldom touch. And if you manually fix some bug in the generated code you will have to manually do the same work in all other possible projects that are based on the same generator.

Roc will push a lot of the code that you would normally get from a generator away from your project and into versioned packages that can be updated and interacted with through a common interface. This means that you do not get code inside your projects that you will not care about most of the time like configuration files and common boilerplate, making it possible to update it. This leaves you with only the most important code inside your project. Additionally Roc is a composable system making it easy to add additional functionality with minimal effort after the initial project setup.

With that said you could definitely use Yeoman together with Roc if you so wish.

Minimal lock-in

Roc tries to stay out of your way as much as possible and most extensions will not introduce any Roc-specific interfaces. Your project will still use your favourite libraries in the same way as you normally would.

Current Official Packages & Plugins

See the repositories under this organisation

Documentation

See the documentation.

Motivation

Roc was born out of the need to create modern applications following the correct conventions and using best practices consistently.

We quickly realized that keeping boilerplate updated within each project over time was unmanageable. It seems natural to have this repeated complexity managed by separated semantically versioned packages.

See this article for a more in-depth overview of the reasoning behind Roc.

Development of Roc was started before these posts where created but they still describe what Roc aims to solve in a good way:

Versioning and stability

Roc follows semantic versioning and is currently pre-release software that will soon be released as stable.

It is already used in production by teams within Schibsted as well as other companies and individuals.

Contribute

We are open to, and grateful for, any contributions made by the community.

Thanks

Thanks to Jongleberry for letting us use the roc package name on npm.