* added tests environment with mongodb 4.4.3 * added CI test for mongodb 4.4.3 * added CI tests for MongoDB versions 4.0, 4.2 * improved flaky test (seems to max out the limit of simultaneous connections) * added spec helpers to run tests only for specific MongoDB version * addedn npm scripts to run tests against relevant mongodb versions * added spec helper function to exclude specific mongodb version * added test for changed aggregate query planner results * fixed regex test with incorrect regex syntax * fixed test where query has select no keys (empty array) * added changelog entry and ordered list * fixed test that tried to simultaneously delete and build index on same collection * added MongoDB compatibility table to readme * updated default local tests to use MongoDB 4.4.3 * added MongoDB badges for new versions to README * fixed typo in readme * added new test helper filter to contribution guide * fixed incorrect storage engine for mongodb 4.4 * changed CI to test MongoDB 3.6. with mmapv1 storage engine and standalone * improved CI test description * added CI self check for new MongoDB versions * fixed CI * removed CI * added CI * added throwing error if any of the checks failed * added github action connector * improved error message * improved error messages * improved error message * updated CI environment to MongoDB 3.6.22 * improved error messages * update CI env name * updated CI env name * improved error message * removed patch versions from CI env description * improved status message * removed version range from core lib * added explicit mongodb version to redis test and node 12 test * bumped Node 12 test to 12.20.1 (version currently recommended by AWS Elastic Beanstalk)
8.6 KiB
Contributing to Parse Server
We really want Parse to be yours, to see it grow and thrive in the open source community.
If you are not familiar with Pull Requests and want to know more about them, you can visit the Creating a pull request article. It contains detailed informations about the process.
Setting up the project for debugging and contributing:
Recommended setup:
- vscode, the popular IDE.
- Jasmine Test Explorer, a very practical test exploration plugin which let you run, debug and see the test results inline.
Setting up you local machine:
- Fork this project and clone the fork on your local machine:
$ git clone https://github.com/parse-community/parse-server
$ cd parse-server # go into the clone directory
$ npm install # install all the node dependencies
$ code . # launch vscode
$ npm run watch # run babel watching for local file changes
To launch VS Code from the terminal with the
codecommand you first need to follow the launching from the command line section in the VS Code setup documentation.
Once you have babel running in watch mode, you can start making changes to parse-server.
Good to know:
- The
lib/folder is not commited, so never make changes in there. - Always make changes to files in the
src/folder. - All the tests should point to sources in the
lib/folder.
Troubleshooting:
Question: I modify the code in the src folder but it doesn't seem to have any effect.
Answer: Check that npm run watch is running
Question: How do I use breakpoints and debug step by step?
Answer: The easiest way is to install Jasmine Test Explorer, it will let you run selectively tests and debug them.
Question: How do I deploy my forked version on my servers?
Answer: In your package.json, update the parse-server dependency to https://github.com/MY_USERNAME/parse-server#MY_FEATURE. Run npm install, commit the changes and deploy to your servers.
Please Do's
- Begin by reading the Development Guide to learn how to get started running the parse-server.
- Take testing seriously! Aim to increase the test coverage with every pull request. To obtain the test coverage of the project, run:
npm run coverage - Run the tests for the file you are working on with the following command:
npm test spec/MyFile.spec.js - Run the tests for the whole project to make sure the code passes all tests. This can be done by running the test command for a single file but removing the test file argument. The results can be seen at <PROJECT_ROOT>/coverage/lcov-report/index.html.
- Lint your code by running
npm run lintto make sure the code is not going to be rejected by the CI. - Do not publish the lib folder.
Run your tests against Postgres (optional)
If your pull request introduces a change that may affect the storage or retrieval of objects, you may want to make sure it plays nice with Postgres.
-
Run the tests against the postgres database with
PARSE_SERVER_TEST_DB=postgres PARSE_SERVER_TEST_DATABASE_URI=postgres://postgres:password@localhost:5432/parse_server_postgres_adapter_test_database npm run testonly. You'll need to have postgres running on your machine and setup appropriately or useDocker. -
The Postgres adapter has a special debugger that traces all the sql commands. You can enable it with setting the environment variable
PARSE_SERVER_LOG_LEVEL=debug -
If your feature is intended to only work with MongoDB, you should disable PostgreSQL-specific tests with:
describe_only_db('mongo')// will create adescribethat runs only on mongoDBit_only_db('mongo')// will make a test that only runs on mongoit_exclude_dbs(['postgres'])// will make a test that runs against all DB's but postgres
-
Similarly, if your feature is intended to only work with PostgreSQL, you should disable MongoDB-specific tests with:
describe_only_db('postgres')// will create adescribethat runs only on postgresit_only_db('postgres')// will make a test that only runs on postgresit_exclude_dbs(['mongo'])// will make a test that runs against all DB's but mongo
-
If your feature is intended to work with MongoDB and PostgreSQL, you can include or exclude tests more granularly with:
it_only_mongodb_version('>=4.4')// will test with any version of Postgres but only with version >=4.4 of MongoDB; accepts semver notation to specify a version rangeit_exclude_mongodb_version('<4.4')// will test with any version of Postgres and MongoDB, excluding version <4.4 of MongoDB; accepts semver notation to specify a version range
Run Postgres setup for Parse with Docker
PostGIS images (select one with v2.2 or higher) on docker dashboard is based off of the official postgres image and will work out-of-the-box (as long as you create a user with the necessary extensions for each of your Parse databases; see below). To launch the compatible Postgres instance, copy and paste the following line into your shell:
docker run -d --name parse-postgres -p 5432:5432 -e POSTGRES_PASSWORD=password --rm postgis/postgis:11-3.0-alpine && sleep 20 && docker exec -it parse-postgres psql -U postgres -c 'CREATE DATABASE parse_server_postgres_adapter_test_database;' && docker exec -it parse-postgres psql -U postgres -c 'CREATE EXTENSION postgis;' -d parse_server_postgres_adapter_test_database && docker exec -it parse-postgres psql -U postgres -c 'CREATE EXTENSION postgis_topology;' -d parse_server_postgres_adapter_test_database
To stop the Postgres instance:
docker stop parse-postgres
You can also use the postgis/postgis:11-2.5-alpine image in a Dockerfile and copy this script to the image by adding the following lines:
#Install additional scripts. These are run in abc order during initial start
COPY ./scripts/setup-dbs.sh /docker-entrypoint-initdb.d/setup-dbs.sh
RUN chmod +x /docker-entrypoint-initdb.d/setup-dbs.sh
Note that the script above will ONLY be executed during initialization of the container with no data in the database, see the official Postgres image for details. If you want to use the script to run again be sure there is no data in the /var/lib/postgresql/data of the container.
Generate Parse Server Config Definition
If you want to make changes to Parse Server Configuration add the desired configuration to src/Options/index.js and run npm run definitions. This will output src/Options/Definitions.js and src/Options/docs.js.
To view docs run npm run docs and check the /out directory.
Feature Considerations
Security Checks
The Parse Server security checks feature warns developers about weak security settings in their Parse Server deployment.
A security check needs to be added for every new feature or enhancement that allows the developer to configure it in a way that weakens security mechanisms or exposes functionality which creates a weak spot for malicious attacks. If you are not sure whether your feature or enhancements requires a security check, feel free to ask.
For example, allowing public read and write to a class may be useful to simplify development but should be disallowed in a production environment.
Security checks are added in SecurityChecks.js.
Code of Conduct
This project adheres to the Contributor Covenant Code of Conduct. By participating, you are expected to honor this code.