# Create a New Service Package

## Scaffold a new service package

HNOD SDK comes with a scaffolding tool that can be used to simplify the creation of a new service package, it can generate a skeleton of an application so that you can kickstart new projects even faster.

On how to run the tool please refer to Create a new Service Package of the Getting Started section.

## The structure of the new project

The newly created service package contains the package.json file with all required dependencies and some scripts that can be used to build and run the service package locally.

### hnod.bundler.json file

hnod.bundler.json contains the configuration for the HNOD bundling tool including:

• name, version, title and description of the service package.
• output specifies a directory where the resulting build artifact will be placed
• inputs specifies an array of entry points of the service package. Each entry point must have a default export that is a RunnableBundle or WebRunnableBundle which exposes the components of the service package.

#### Assets and Resources

If the service package needs to use static resources, they should also be configured here. There are two ways:

• resources - list of resources that will be loaded every time at runtime from the portal. For more details, see the Coffee To Go example.
• assetsExtensions - list of file extensions that will be processed as webpack assets. Such assets can be imported at the usage site like additional modules and webpack will inject a suitable representation at runtime. Each assset extensions is either configured by providing a simple string that contains the file extension or by providing a config object of the form {"type": $extension, "as":$loader}, where:
• $extension is a string that specifies the file extension that this configuration applies to • $loader is a string that specifies the loader for the file extension. This determines how assets are injected. Currently the following values are supported:
• url configures the url-loader for this extension type. This type of loader is also chosen when the file extension is configured as a simple string. When this loader is used, assets with this file extension will be transformed into base64-encoded data-URIs and embedded into the resulting code. This approach is most suitable for small assets that should be available immediately. This type of loader is also more suitable for assets that need to be available in offline mode.
• file configures the file-loader for this extension type. When this loader is used, assets with this file extension will be injected as a URL to the actual resource on the HNoD portal. When using this loader, the service package also needs to set webpack's public path correctly. Assets using this loader are currently not cached for offline useage.

Below you can see an example of hnod.bundler.json file that is generated by the scaffolding tool:

{
"name": "com.myorganization.hnod.example",
"version": "0.0.1",
"title": "Example Service Package",
"description": "This is a simple example service package.",
"output": "output",
"inputs": ["./lib/bundles/ExampleBundle.js"],
"assetsExtensions": ["png"]
}


### Dependencies configuration

hnod.bundler.json can contain declarations of provided and required funtionality, see service package dependencies. Every artifact is uniquely defined in the HNOD scope with its name and type (in the current implementaion there's one possible value - trait). The configuration contains two sections:

• requires - array of artifacts with specified ranges of versions
• provides - array of artifacts provided by the package with specified version

For example:

  "requires": [
{
"artifact": {
"name": "com.here.hnod.feature.fs.context",
"type": "trait"
},
"versionRange": "1.0.0"
}
],
"provides": [
{
"artifact": {
"name": "com.here.hnod.feature.fs0.core.service",
"type": "trait"
},
"version": "1.0.0"
}
]


## Version templates

Version values in hnod.bundler.json can be set using templates with config parameter in package.json:

  "config": {
"packageVersion": "1.0.2"
}


For example:

if packageVersion is set in package.json then line:

"version": "{{#packageVersionTemplate}}1.0.0{{/packageVersionTemplate}}"


in hnod.bundler.json will be converted to:

"version": "1.0.2"


otherwise, if packageVersion isn't defined then the default value from the hnod.bundler.json (1.0.0) will be set

### hnod.runner.json file

hnod.runner.json file describes the configuration of the HNOD runner which can be used to run and test the service package on the local environment before it's published to HNOD portal and delivered to clients. It contains:

• port field which is a local port on which the simulation tool will be running.
• packages which is an array of references to services package archives built by HNOD bundler.

The HNOD runner config file generated by the scaffolding tool looks as follows:

{
"port": 8081,
"packages": ["./output/com.myorganization.hnod.example.zip"]
}


### src directory

src directory contains the source code of the service package and in the generated example includes directories bundles and components.

In the bundles directory there is an ExampleBundle class that implements WebRunnableBundle interface which is an entry point of the service package, components() method of this class returns a list of cards that the service package contains so that they could be registered in the HNOD application and menuItems() returns a menu component that is, for instance, added in the service menu so that the application can be started from the HNOD service launcher.

Under components directory there are several classes representing the UI elements of the service package, all of them are react components and a service package can contain one or multiple cards that extend CardStackScreen with a render method returning a SmartCard. The required properties of the SmartCard minimized and disabled are already available in the CardStackScreen. Cards can be pushed to the application card stack or popped from the stack using the corresponding methods of CardStackModel.

Please see HNOD SDK API Reference for more details.