> For the complete documentation index, see [llms.txt](https://cubbles.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cubbles.gitbook.io/docs/develop/developing-vanilla-boilerplate/available-scripts.md).

# Using the vanilla boilerplate scripts

The [vanilla boilerplate](https://github.com/cubblesmasters/vanilla) includes 13 scripts listed in the `package.json` file. However, in this tutorial, we will present only 9, which are the ones that you will require to develop, deploy and upload Cubbles artifacts.

## Prerequisites

To start using the scripts of the `vanilla boilerplate`, it should be cloned locally and all its dependencies should be installed (See [this guide](/docs/develop/developing-vanilla-boilerplate/creating-project.md) for more information).

## Running the scripts

You can run all the available scripts using npm as follows:

```bash
npm run [script-name]
```

Also, you can install [ntl](https://www.npmjs.com/package/ntl) globally and the run it to access the scripts as shown below:

```bash
$ ntl
✔  Npm Task List - v3.0.0
? Select a task to run: (Use arrow keys)
❯ build
  build:watch
  build:prod
  clean
  upload
  upload:prod
  validate-manifest
(Move up and down to reveal more choices)
```

## Building a dist version of your webpackage

TO be able to test a developed artifact you should build a dist version that can be run under the Cubbles platform. That is, it should be within a [webpackage](/docs/develop/terms-and-concepts/webpackage.md) that contains a [valid manifest file](http://cubbles.github.io/cubx-webpackage-document-api/schema-explorer.html?schemaPath=https://raw.githubusercontent.com/cubbles/coder-toolset/develop/packages/webpackage-document-api/lib/jsonSchema/manifestWebpackage-10.1.0.schema.json). To aim that, you should run one of the building scripts which are:

* **build**: builds a development version of the current webpackage.
* **build:watch**: builds a development version of the current webpackage, and monitors changes to produce new builds when required.
* **build:prod**: builds a production version (i.e., with minified scripts) of the webpackage.

The built webpackage will be placed in a folder called `dist` in the root folder of your project.

## Starting a local server

After building a webpackage, you may want to run it locally. To aim that, you can run one of the following scripts:

* **start**: it starts a local web server listening at *http:localhost:4000*.
* **start:watch**: it starts a local web server listening at *http:localhost:4000* and monitoring changes to reload the server when needed.

## Uploading a webpackage to a Cubbles base

When your webpackage is ready, you may want to upload it to a Cubbles base. There two scripts that you can use for uploading:

* "upload": this script is intended to be used during development. It uploads the webpackage using the configuration defined in the `cubx-uploader-config.dev` property of the `cubbles[cubx-webpackage-uploader]` property of the *package.json* file. The script offers you the opportunity to build the webpackage using the `build` script.
* "upload:prod": this script is intended to be used for production. It uploads the webpackage using the configuration defined in the `cubx-uploader-config.prod` property of the `cubbles[cubx-webpackage-uploader]` property of the *package.json* file.. The script offers you the opportunity to build the webpackage using the `build:prod` script.

Both scripts run the `validate-manifest` script before trying to upload the webpackage. If the generated manifest is invalid the webpackage would not be uploaded.

### Upload configuration files

As mentioned above, upload configuration files are located at the root of your folder. Those are JSON files, containing the following properties:

1. `target [mandatory, object]`: This object contains the following properties:
   1. `url [mandatory, string/url]`: This is the url of the Cubbles Base where the webpackage will be uploaded to.
   2. `proxy [optional, string/url]`: If your connection to the Cubbles Base is routed over a proxy server, use this attribute to provide the proxy url.
2. `dryRun [optional, boolean]`: This option allows you to run the task, without actually uploading anything. It's perfect to check your permissions to upload to the target base.
3. `debug [optional, boolean]`: Set the debug option to "true" to print more details of the uploading process.

You should edit those properties according to your needs.

## Validating de generated (built) manifest

The manifest of a Cubbles webpackage should be valid according to a JSON schema associated with a model version. Up [RTE@3.0.0](/docs/develop/runtime-extension-rte.md) the modelVersion is 10.0.0, whose JSON schema can be explored [online](http://cubbles.github.io/cubx-webpackage-document-api/schema-explorer.html?schemaPath=https://raw.githubusercontent.com/cubbles/coder-toolset/develop/packages/webpackage-document-api/lib/jsonSchema/manifestWebpackage-10.1.0.schema.json).

If you want to be sure that the generated manifest is valid, you can run the `validate-manifest` script.

Note that this script is run automatically before uploading a webpackage. That is when running `upload` or `upload:dev` scripts.

## Cleaning the dist folder

Finally, if you want to clean (remove) the generated *dist* folder, you can run the `clean` script. Note, that it is run automatically when running `build` or `build:dev` scripts.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://cubbles.gitbook.io/docs/develop/developing-vanilla-boilerplate/available-scripts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.