yukon - npm Package Compare versions

Comparing version 1.4.4 to 1.4.5

demoServer.js

travis.yml

package.json

		{
		"name": "yukon",
		"version": "1.4.4",
		"version": "1.4.5",
		"description": "Self-discovering data-driven web components",
		@@ -21,3 +21,3 @@ "main": "yukon.js",
		"scripts": {
		"test": "echo \"Error: no test specified\" && exit 1"
		"test": "make test"
		},
		@@ -24,0 +24,0 @@ "repository": {

README.md

		@@ -5,4 +5,7 @@               ![North to the Yukon!](http://i.imgur.com/gBj7RWo.gif)

		[![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/jackspaniel/yukon?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
		[![NPM Version][npm-image]][npm-url]
		[![NPM Downloads][downloads-image]][downloads-url]
		[![build status][travis-image]][travis-url]
		[![Test coverage][coveralls-image]][coveralls-url]

		@@ -63,3 +66,3 @@ yukon is a component-based, datasource-agnostic framework for serving web content. It extends the [nodulejs component framework](https://github.com/jackspaniel/nodulejs) - to include back-end data gathering, standardized slots for app-defined middleware and template management.

		Our feature devs spend 80-90% of their effort in jade templates or on the client side. For them, node components are often mostly a pass-through to our back-end API(s)--with some business logic applied to the request on the way in, and api data on the way out. Ideally they should have to learn the as little as possible of the vagaries/plumbing/whatever-your-favorite-metaphor-for-framework-stuff of node. Creating a new node component should be as easy for them as creating a new JSP - but again, without the framework losing control of the middleware chain.
		Our feature devs spend 80-90% of their effort in jade templates or on the client side. For them, node components are often mostly a pass-through to our back-end API(s)--with some business logic applied to the request on the way in, and API data on the way out. Ideally they should have to learn the as little as possible of the vagaries/plumbing/whatever-your-favorite-metaphor-for-framework-stuff of node. Creating a new node component should be as easy for them as creating a new JSP - but again, without the framework losing control of the middleware chain.

		@@ -151,6 +154,9 @@ From a __framework-development point of view__, we knew that as requirements evolved, we would constantly need to add default properties to each component, while hopefully causing as little disruption as possible to existing components. This is easily accomplished by adding a default property to the base config, then specifying the property only in the nodules that need the new property.
		```
		### To Run Demo App as Standalone
		```
		$ node demoServer
		```
		## To Do
		1. Reconsider stub behavior for parallel-api. Should all stubs move to apiSim behavior? What about brand new nodules where nothing is known about the API yet?
		2. Get demoApp working as standalone.
		3. Hook up Travis CI and code coverage.
		2. Hook up Travis CI and code coverage.

		@@ -335,1 +341,6 @@ ## Features for future consideration
		[downloads-url]: https://npmjs.org/package/yukon
		[travis-image]: https://img.shields.io/travis/yukon/yukon/master.svg?style=flat-square
		[travis-url]: https://travis-ci.org/yukon/yukon
		[coveralls-image]: https://img.shields.io/coveralls/yukon/yukon/master.svg?style=flat-square
		[coveralls-url]: https://coveralls.io/r/yukon/yukon?branch=master

yukon - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics

Worsened metrics