Configuring the CSS as a development server in another project¶
It can be useful to use the CSS as local server to develop Solid applications against. There are several ways to configure and run a server in your project. Note that starting up the server takes some time so set your timeout high enough if you are using this in your tests.
Starting the server through code¶
You can create a server instance in your code, or tests, by calling the create
function of a new AppRunner
instance.
The resulting object has start
and stop
functions.
The create
function takes as input an object with 5 optional parameters
which can all be used to define the server configuration.
None of these are mandatory, if you don't think you need one you can probably ignore it.
These are discussed below.
loaderProperties¶
These values are specifically to configure how Components.js handles starting the server. Most of these are generally not going to be relevant, but here are some of those you might want to change:
- mainModulePath: Determines where Components.js will look for components. Defaults to the folder where the server dependency is installed. In case you are making a custom component, this value needs to point to the directory of your project instead.
- logLevel: The logging level of Components.js when building. Defaults to
warn
.
config¶
The file path of the Components.js configuration that needs to be used.
This can also be an array of configuration paths.
The @css:
prefix can be used for file paths to generate a path
relative to the folder where the server dependency is installed.
Defaults to @css:config/default.json
.
variableBindings¶
Allows you to assign values to the variables that are used in a Components.js configuration.
For example, { 'urn:solid-server:default:variable:port': 3000 }
tells the server to use port 3000.
shorthand¶
Allows you to assign values to parameters similarly as if you would call the server from the CLI.
For example, { port: 3000 }
tells the server to use port 3000.
This is very similar to the variableBindings
field mentioned above,
as CLI parameters all get translated into Components.js variables,
although some get transformed before being put into a variable.
If you are not sure which one to use, shorthand
is the safer choice to use.
argv¶
If used, this parameter expects a string array. Here you can provide the raw dump of CLI values, so you don't have to parse them yourself, should this be useful for your application.
Configuring the server in package.json
¶
As an alternative to using CLI arguments, or environment variables, the CSS can be configured in the package.json
as follows:
{
"name": "test",
"version": "0.0.0",
"private": "true",
"config": {
"community-solid-server": {
"port": 3001,
"loggingLevel": "error"
}
},
"scripts": {
"dev:pod": "community-solid-server"
},
"devDependencies": {
"@solid/community-server": "^7.0.0"
}
}
These parameters will then be used when the community-solid-server
command is executed as an npm
script (as shown in the example above).
Or whenever the community-solid-server
command is executed in the same
folder as the package.json
.
Alternatively, the configuration parameters may be placed in a configuration file named
.community-solid-server.config.json
as follows:
{
"port": 3001,
"loggingLevel": "error"
}
The config may also be written in JavaScript with the config as the default export
such as the following .community-solid-server.config.js
:
module.exports = {
port: 3001,
loggingLevel: 'error'
};