add-schema Add Saltcorn schema to existing database
backup Backup the PostgreSQL database to a file with pg_dump or zip
create-tenant Create a tenant
create-user Create a new user
If you don't see this, then something has gone wrong.
You also need to tell Saltcorn how it will connect to a database. You can do this just by running
Select the development option which will use SQLite. Now you should be able to run with
Connect to http://localhost:3000 and set up your account
You are now ready to edit any of the files in the saltcorn repository. When you save a file, the server does not automatically pick up changes. You can press Ctrl+C to restart it, and then you should see your changes if you read out the page in the browser.
The nodemon tool make this process a bit easier. It can watch for file changes and restart the server automatically when it sees changes. To run the Saltcorn server with nodemon, run
nodemon `which saltcorn` serve
Saltcorn uses one worker process per CPU core. This may slow down start-up if you have a lot of cores. To reduce the number of worker processes, set the SALTCORN_NWORKERS environment variable
Tests are run using the run-tests command in the saltcorn cli command. This is optionally followed by a package name, in which case only the tests for that package will be run. If no package is specified, then the test for all packages are run. Note that the package name here is the directory name in packages/, not the formal NPM package name (e.g. saltcorn-data, not @saltcorn/data)
The tests are run against a real database, which needs to be reset multiple times during the test runs. The implications of this for your ongoing application development depends on which database backend you are using.
If you are using the SQLite database, it will use whatever the file /tmp/sctestdb as the database. It will not affect applications in different files
You can at any time switch to a SQLite-based test runner - whenever the SQLITE_FILEPATH environment variable is set, Saltcorn will use the SQLite backend, even if the configuration file is set up to use PostgreSQL. Environment variables in general overwrite the configuration file. SQLITE_FILEPATH=/tmp/sqlite.db saltcorn run-tests saltcorn-data
If Saltcorn is configured to use PostgreSQL, it will switch to connect to the saltcorn_test database, which must be present on the same database and accessed with the same credentials as those configured in your configuration file or environment variables. Running the tests will therefore not affect any applications you are developing as these will be located in a different database.
In order for the tests related to multi tenancy to work, you should have the following lines in your /etc/hosts file:
The drag-and-drop builder used to build pages and views is a React component which is compiled separately. Its source package is in packages/saltcorn-builder in the saltcorn repository. The build artefact is checked into version control and part of the saltcorn-builder NPM package as dist/builder_bundle.js. This is done to avoid needless rebuilds and to reduce the size of the node_modules installed. In the saltcorn-builder package, the build npm script can be used to rebuild this bundle, which is imported and statically served by the Saltcorn server process
This regenerates dist/builder_bundle.js. Subsequent builds can be performed with
npm run build
You can also perform a development build, which is faster to build, gives you better error messages but a larger bundle
npm run builddev
Running either the production or the development build will be picked up if you are running a nodemon saltcorn server in a different terminal window.
In order to get continuous builds, without needing to re-run the build script manually, you can use the entr tool (installed through your OS package manager):
git ls-files | entr npm run builddev
in the saltcorn-builder directory. If you run the nodemon process in one terminal window and the above command in a different terminal window, you should see any changes after saving a source file and reloading the page. This is a little bit slower as both the rebuild needs to finish and the server need to reload.