		{
		"name": "smoke",
		"description": "JS Build Tool",
		"author": "Damon Oehlman <damon.oehlman@sidelab.com>",
		"tags": [
		"build"
		"version": "1.0.0",
		"description": "Simple yet powerful file-based mock server",
		"main": "smoke.js",
		"bin": {
		"smoke": "./bin/smoke"
		},
		"scripts": {
		"lint": "xo",
		"lint:fix": "xo --fix",
		"start": "smoke test/mocks",
		"test": "xo && jest",
		"postpublish": "git tag -a $npm_package_version -m \"$npm_package_version\" && git push --tags"
		},
		"keywords": [
		"mock",
		"server",
		"api",
		"file",
		"file-based",
		"json",
		"rest",
		"template"
		],
		"version": "0.0.0",
		"engines": {
		"node": ">= 0.4.x < 0.7.0"
		},
		"main": "./lib/smoke.js",
		"author": "Yohan Lasorsa",
		"license": "MIT",
		"dependencies": {
		"async": "0.1.x",
		"debug": "*",
		"findit": "0.1.x",
		"minimatch": "0.2.x",
		"mkdirp": "0.3.x",
		"nopt": "1.x.x",
		"pipeline": "git://github.com/DamonOehlman/pipeline.git",
		"out": "*",
		"sniff": "0.1.x"
		"body-parser": "^1.18.3",
		"express": "^4.16.4",
		"fs-extra": "^7.0.1",
		"globby": "^8.0.1",
		"import-fresh": "^2.0.0",
		"lodash.template": "^4.4.0",
		"minimist": "^1.2.0",
		"morgan": "^1.9.1",
		"multer": "^1.4.1",
		"path-to-regexp": "^2.4.0"
		},
		"devDependencies": {
		"expect.js": "0.1.x",
		"mocha": "1.x.x",
		"rigger": "0.2.x"
		"jest": "^23.6.0",
		"supertest": "^3.3.0",
		"xo": "^0.23.0"
		},
		"optionalDepencies": {
		"xo": {
		"space": true,
		"prettier": true,
		"envs": [
		"node",
		"jest"
		],
		"ignores": [
		"test/mocks/*/"
		]
		},
		"repository": {
		"type": "git",
		"url": "git://github.com/DamonOehlman/smoke.git"
		},
		"bugs": {
		"url": "http://github.com/DamonOehlman/smoke/issues"
		},
		"scripts": {
		"test": "mocha --reporter spec -t 10000"
		},
		"contributors": [],
		"optionalDependencies": {}
		"engines": {
		"node": ">=8.0.0"
		}
		}

229

README.md

		@@ -1,27 +0,222 @@
		# Smoke
		# :dash: smoke

		Smoke will be a JS build tool that will replace [Interleave](https://github.com/DamonOehlman/interleave). A lot has been learned over the last six months and it's time to start with a clean slate and create a tool that make it a breeze to build re-usable, tested JS for as many environments as possible.
		[![NPM version](https://img.shields.io/npm/v/smoke.svg)](https://www.npmjs.com/package/smoke)
		[![Build status](https://img.shields.io/travis/sinedied/smoke/master.svg)](https://travis-ci.org/sinedied/smoke)
		![Node version](https://img.shields.io/node/v/smoke.svg)
		[![XO code style](https://img.shields.io/badge/code_style-XO-5ed9c7.svg)](https://github.com/sindresorhus/xo)
		[![License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)

		__CURRENT STATUS:__ [Call for Issues](https://github.com/DamonOehlman/smoke/issues)
		> Simple yet powerful file-based mock server

		You know best what you need in a build tool. I only know what I need. To make sure what is developed meets the broadest possible requirements please [log issues](https://github.com/DamonOehlman/smoke/issues/new) and engage in discussion.
		![demo](https://user-images.githubusercontent.com/593151/49312821-9f2cc680-f4e5-11e8-900a-117120c38422.gif)

		## Use Grunt
		Just drop a bunch of (JSON) files in a folder and you're ready to go!

		After working with the [Grunt API](https://github.com/cowboy/grunt/blob/master/docs/api.md) and successfully integrating Rigger with grunt (via the [grunt-rigger plugin](https://github.com/DamonOehlman/grunt-rigger)) it's highly unlikely that I'm going to put any effort into building __yet another build tool__. Grunt will likely to exactly what you need, and it's got some great features already baked in that make it a whole pile of JS build yumminess. You should definitely try it out!
		#### Basic mock example:
		1. Start the server: `smoke`
		2. Create a file named `get_api#hello.json`:
		```json
		{
		"message": "hello world!"
		}
		```
		3. Test the mock: `curl http://localhost:3000/api/hello`

		## General Design Goals
		#### Features

		1. Very [Stream](http://nodejs.org/docs/latest/api/stream.html) centric.
		2. Pluggable API
		3. Do as little as possible in the core, with composition through streams (1) and an API (2) this should be absolutely fine.
		Smoke is a file-based, convention over configuration mock server that can fill your API mocking needs without any
		complex setup. Yet, it supports many advanced features and dynamic mocks for almost any situation:

		## Component Pieces
		- Use folders and file names to describe API routes and REST methods
		- Use templates to generate responses based on input queries and route parameters
		- Add / edit / remove mocks without restarting the server
		- Generate mocks with JavaScript for more complex responses
		- Define different mock sets to simulate various scenarii (errors...), with fallback
		- Customize headers and status code if needed, automatically detect content-type if not specified

		Some of the component pieces required to build smoke have already been built:
		## Installation

		1. [Rigger](/DamonOehlman/rigger) - Include files in other files
		2. [StreamClean](/DamonOehlman/streamclean) - Remove or change lines in a stream
		3. [Pipeline](/pgte/pipeline) or [event-stream](/dominictarr/event-stream) - useful helpers for combining streams, and in event event-stream's case nice helpers for making an async function slot into a piped stream simply.
		4. [jshint](https://github.com/jshint/node-jshint)
		5. [UglifyJS](https://github.com/mishoo/UglifyJS)
		```bash
		npm install -g smoke
		```

		## Usage

		See [some example mocks](test/mocks) to quickly get a grasp of the syntax and possibilities.

		CLI usage is quite straightforward:
		```
		Usage: smoke [<mocks_folder>] [options]

		Options:
		-p, --port <num> Server port [default: 3000]
		-h, --host <host> Server host [default: "localhost"]
		-s, --set <name> Mocks set to use [default: none]
		-n, --not-found <glob> Mocks for 404 errors [default: "404.*"]
		-l, --logs Enable server logs
		-v, --version Show version
		--help Show help
		```

		### File naming

		General format: `methods_api#route#:param.set.extension`

		The path and file name of the mock is used to determinate:

		#### Supported HTTP methods
		Optionally prefix your file by the HTTP method supported followed by an underscore (for example `get_`).
		You can specify multiple methods at once using a `+` to separate them (for example `post+put_`);
		If no method is specified, the mock will be used for any HTTP method.

		#### Server route and named route parameters
		Use any combination of folders or hash-separated components to specify the server route.

		For example `api/example/get_hello.json` is equivalent to `get_api#example#hello.json` and will repond to
		`GET api/example/hello` requests.

		Additionaly, any route component can be defined as a route parameter by prefixing the name with `:`, for example
		`api#resource#:id.json` will match `GET api/resource/1` and expose `1` as the value for the `id` parameter that can be
		used in dynamic mocks (templates or JavaScript).

		#### Content type
		The file extension will determine the content type of the response if it's not already specified in a
		[custom header](#custom-status-and-headers).

		Files with no extension will use the default MIME type `application/octet-stream`.

		You can have multiple mocks with the same API route and different file extensions, the server will then use the best
		mock depending of the [`Accept` header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept) of the
		request.

		#### Mock set
		You can optionally specify a mock set before the file extension by using a `.set-name` suffix after the file name.

		For example `get_api#hello.error.json` will only be used if you start the server with the `error` set enabled:
		`smoke --set error`.

		If you do not specify a mock set on your file name, it will be considered as the default mock for the specified route
		and will be used as a fallback if no mock with this set matched.

		#### Templates
		If you add an underscore `_` after the file extension, the mock will be processed as a template before being sent to
		the client. Templates works only on text-based formats.

		For example `get_hello.html_` or `get_hello.json_` will be treated as templates.

		Every template can use an implicit context object that have these properties defined:
		- `method`: the HTTP method of the request (ex: `'GET'`, `'POST'`)
		- `query`: map with query parameters that were part of the request URL. For example, matched URL
		`http://server/hello?who=world` will result in the query value: `{ who: 'world' }`.
		- `params`: map containing matched route parameters. For example the mock `resource#:id.json` with the matched URL
		`http://server/resource/123` will result in the params value: `{ id: '123' }`.
		- `headers`: map containing request headers
		- `body`: the request body. JSON bodies are automatically parsed.
		- `files`: if the request includes `multipart/form-data`, this will be the array of uploaded files (see
		[multer documentation](https://github.com/expressjs/multer) for more details)

		##### Template syntax

		- `{{ }}` interpolates data in place

		For example, create get_hello.txt_ with this:
		```
		Hello {{query.name}}!
		```

		Then `curl "http://localhost:3000/hello?name=John"` returns `Hello John!`

		- `{{{ }}}` escapes HTML special chars from interpolated string

		For example, create get_hello.html_ with this:
		```html
		<h1>Hello {{{query.name}}}!</h1>
		```

		Then `curl "http://localhost:3000/hello?name=%3CJack%26Jones%3E"` returns:
		```html
		<h1>Hello <Jack&Jones>!</h1>
		```

		- `<{ }>` evaluates JavaScript to generate data

		For example, create get_hello.html_ with this:
		```html
		Hello to:
		<ul>
		<{ query.name.forEach(name => { }><li>{{name}}</li><{ }); }>
		</ul>
		```

		Then `curl "http://localhost:3000/hello?name=Jack&name=Jones"` returns:
		```html
		Hello to:
		<ul>
		<li>Jack</li><li>Jones</li>
		</ul>
		```

		### Custom status and headers

		By default all mocks responses are sent with a status code `200` (OK), or `204` (No content) if a mock file is empty.

		You can customize the response status and (optionally) headers with JSON and [JavaScript](#javascript-mocks) files,
		using this syntax:
		```js
		{
		"statusCode": 400,
		"body": {
		"error": "Bad request"
		},
		// headers can be omitted, only use if you want to customize them
		"headers": {
		"Content-Type": "text/plain"
		}
		}
		```

		### Mock formats

		Any file format is supported for mocks, and the file extension will be used to determine the response content type.
		Files with no extension will use the default MIME type `application/octet-stream`.

		Text formats (for example `.json`, `.html`, `.txt`...) can be processed as [templates](#templates) by adding an
		underscore to the file extension.

		Note that JSON files and templates must use `UTF-8` encoding.

		#### JavaScript mocks

		In addition, you can define dynamic mocks using JavaScript by using the `.js` extension, that will be loaded as a regular
		NodeJS module.

		In that case, your JS module is expected to export a function that take an input data object with the
		[same properties](#templates) as for templates and must returns the response body or an
		[object](#custom-status-and-headers) containing the status code, headers and body.

		Example:
		```js
		module.exports = (data) => `Your user agent is: ${data.headers['user-agent']}`;
		```

		Note that by default, JS mocks use `application/json` for the response content type. If you want to use another type,
		you must set the `Content-Type` header yourself, for example:
		```js
		module.exports = data => ({
		statusCode: 200,
		headers: {
		'Content-Type': 'text/plain'
		},
		body: `Your user agent is: ${data.headers['user-agent']}`
		});
		```

		## Other mock servers

		If you cannot find what you need here, you might want to check out one of these other mock servers:

		- [JSON Server](https://github.com/typicode/json-server)
		- [mockserver](https://github.com/namshi/mockserver)
		- [node-mock-server](https://github.com/smollweide/node-mock-server)
		- [node-easymock](https://github.com/CyberAgent/node-easymock)
		- [mockserver-node](https://github.com/jamesdbloom/mockserver-node)

.npmignore

lib/handler.js

lib/smoke.js

lib/smoker.js

test/sample1/dist/test.js

test/sample1/smoke.js

test/sample1/src/js/test.js

bin/smoke

Sorry, the diff of this file is not supported yet

smoke - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics

Worsened metrics

Dependency changes