<commit_before>![The Low-Profile Dog Hoodie Mascot](https://avatars1.githubusercontent.com/u/1888826?v=3&s=200)

# Welcome to `hoodie-server!` 🎉

[![Build Status](https://travis-ci.org/hoodiehq/hoodie-server.svg?branch=next)](https://travis-ci.org/hoodiehq/hoodie-server)
[![Coverage Status](https://coveralls.io/repos/hoodiehq/hoodie-server/badge.svg?branch=next&service=github)](https://coveralls.io/github/hoodiehq/hoodie-server?branch=next)
[![Dependency Status](https://david-dm.org/hoodiehq/hoodie-server/next.svg)](https://david-dm.org/hoodiehq/hoodie-server/next)
[![devDependency Status](https://david-dm.org/hoodiehq/hoodie-server/next/dev-status.svg)](https://david-dm.org/hoodiehq/hoodie-server/next#info=dependencies)


`hoodie-server` is the core server component of Hoodie. Together with `hoodie-client`, it forms the two parts that make up the Hoodie system.

`hoodie-server` is responsible for a number of things on the server:

- check the environment to make sure Hoodie can run properly
- start an instance of CouchDB, Hoodie’s database
- start a webserver each for the Hoodie app itself and the Hoodie Admin Dashboard
- start all Hoodie plugins that might be installed

`hoodie-server` isn’t meant to be used by itself and it is used by the `hoodie` module, which also inlcude `hoodie-client` to form Hoodie.

You can use `hoodie-server` on its own, if you want to work on it, help fix bugs or test new versions. And when you are writing your own plugin, you can use `hoodie-server` for debugging.

## Usage

As noted before, this isn’t meant to be run standalone, but if you are helping out with development, or build your own plugins, or just want to spelunk around, here’s how it works:

```
git clone <EMAIL>:hoodiehq/hoodie-server.git
cd hoodie-server
npm install
npm link
cd ..
git clone <EMAIL>:hoodiehq/hoodie.git
cd hoodie
npm install
npm link hoodie-server
```

When that’s done, you can run `./bin/start` to start `hoodie` with your local `hoodie-server`.

There are a few options to change the behaviour of `hoodie-server`.

path: Project path (optional) Default: process.cwd()
loglevel: (optional) Default: 'warn'

port: Port-number to run the Hoodie App on (optional)
bindAddress': Address that Hoodie binds to (optional) Default: 127.0.0.1
www: WWW path (optional) Default: path.join(options.path, 'www')

adminPort: Port-number to run the admin-dashboard on (optional)
adminPassword: Password for the admin-dashboard (required on first run)

dbPort: Port-number to run the PouchDB Server on (optional)
inMemory: Whether to start the PouchDB Server in memory (optional) Default: false
dbPassword: Password to use for the PouchDB Server `_hoodie` admin user (optional)
dbUrl: If provided does not start PouchDB Server and uses external CouchDB. Has to contain credentials. (optional)
data: Data path (optional) Default: path.join(options.path, 'data')

If that doesn’t make much sense just yet, don’t worry about it.

## Testing

The `hoodie-server` test suite is run with `npm test`.

The tests live in `test/unit` and `test/integration`. `test/unit` tests (or “unit tests”) are to test the behaviour of individual sub-modules within `hoodie-server`, while `test/integration` tests (or “integration tests”) are used to test the behaviour of a fully running instance of `hoodie-server`, e.g. the behaviour of its HTTP API.

If you are adding new features to `hoodie-server` you should provide test cases for the new feature. Depending on the feature, you either best write unit tests or integration tests and sometimes even both. The more tests we have, the more confidently we can release future versions of `hoodie-server`.

## Need Help?

// how to ask for support
//  chat
//  issues
// how to file bug reports

## Wanna help?

// point to hoodie/CONTRIBUTING.md

## License

Apache 2.0
<commit_msg>docs(README): update<commit_after>![The Low-Profile Dog Hoodie Mascot](https://avatars1.githubusercontent.com/u/1888826?v=3&s=200)

# Welcome to `hoodie-server!` 🎉

[![Build Status](https://travis-ci.org/hoodiehq/hoodie-server.svg?branch=next)](https://travis-ci.org/hoodiehq/hoodie-server)
[![Coverage Status](https://coveralls.io/repos/hoodiehq/hoodie-server/badge.svg?branch=next&service=github)](https://coveralls.io/github/hoodiehq/hoodie-server?branch=next)
[![Dependency Status](https://david-dm.org/hoodiehq/hoodie-server/next.svg)](https://david-dm.org/hoodiehq/hoodie-server/next)
[![devDependency Status](https://david-dm.org/hoodiehq/hoodie-server/next/dev-status.svg)](https://david-dm.org/hoodiehq/hoodie-server/next#info=dependencies)


`hoodie-server` is the core server component of Hoodie. Together with `hoodie-client`, it forms the two parts that make up the Hoodie system.

`hoodie-server` itself is responsible for only a few things:

- provide a normalized [config](lib/config.js) for itself and all core components/plugins
- provide an API to interact with [databases](lib/database.js) to components/plugins
- start and configure a [hapi server](lib/hapi.js) that also serves [static components](lib/static.js) like hoodie-client and hoodie-admin-dashboard

The rest is handled by components like [hoodie-server-account](https://github.com/hoodiehq/hoodie-server-account), or [hoodie-server-store](https://github.com/hoodiehq/hoodie-server-store).

`hoodie-server` isn’t meant to be used by itself and it is used by the `hoodie` module, which also inlcudes `hoodie-client` to form Hoodie.

You can use `hoodie-server` on its own, if you want to work on it, help fix bugs or test new versions. And when you are writing your own components/plugins, you can use `hoodie-server` for debugging.

## Usage

As noted before, this isn’t meant to be run standalone, but if you are helping out with development, or build your own components/plugins, or just want to spelunk around, here’s how it works:

```
git clone <EMAIL>:hoodiehq/hoodie-server.git
cd hoodie-server
npm install -g hoodie-start
npm install
hoodie-start
```

There are a few options to change the behaviour of `hoodie-server`.

path: Project path (optional) Default: process.cwd()
loglevel: (optional) Default: 'warn'

port: Port-number to run the Hoodie App on (optional)
bindAddress': Address that Hoodie binds to (optional) Default: 127.0.0.1
www: WWW path (optional) Default: path.join(options.path, 'www')

inMemory: Whether to start the PouchDB Server in memory (optional) Default: false
dbUrl: If provided does not start PouchDB Server and uses external CouchDB. Has to contain credentials. (optional)
data: Data path (optional) Default: path.join(options.path, 'data')

If that doesn’t make much sense just yet, don’t worry about it.

## Testing

The `hoodie-server` test suite is run with `npm test`.

The tests live in `test/unit` and `test/integration`. `test/unit` tests (or “unit tests”) are to test the behaviour of individual sub-modules within `hoodie-server`, while `test/integration` tests (or “integration tests”) are used to test the behaviour of a fully running instance of `hoodie-server`, e.g. the behaviour of its HTTP API.

If you are adding new features to `hoodie-server` you should provide test cases for the new feature. Depending on the feature, you either best write unit tests or integration tests and sometimes even both. The more tests we have, the more confidently we can release future versions of `hoodie-server`.

## Need help or want to help?

It’s best to join our [chat](http://hood.ie/chat/).

## License

Apache 2.0

{'fraction_non_alphanumeric': 0.10641711229946524, 'fraction_numerical': 0.0053475935828877, 'mean_word_length': 4.767925983037779, 'pattern_counts': {'":': 0, '<': 6, '<?xml version=': 0, '>': 6, 'https://': 20, 'lorem ipsum': 0, 'www.': 4, 'xml': 0}, 'pii_count': 2, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6825900', 'n_tokens_mistral': 2349, 'n_tokens_neox': 2271, 'n_words': 890}