Your development workstation needs to have at least 8GB RAM or more to be able to build the Rocket.Chat's source code.
meteor npm install && meteor
It should build and run the application and database for you, now you can access the UI on (http://localhost:3000)
It's not necessary to install Nodejs or NPM, every time you need to use them you can run
meteor node or
It's important to always run the NPM commands using
meteor npm to ensure that you are installing the modules using the right Nodejs version.
We provide a .editorconfig file that will help you to keep some standards in place.
We are currently adopting React over Blaze as our UI engine, the current codebase is under migration and will continue. You will still find Blaze templates in our code. Code changes or contributions may need to be made in Blaze while we continue to evolve our components library.
The Fuselage is our component library based on React, check it out when contributing to the Rocket.Chat UI and feel free to contribute new components or fixes.
Things not covered by
Prefer longer/descriptive variable names, e.g.
err, unless dealing with common record properties already shortened, e.g.
Use return early pattern. See more
then/catch (also valid for unit/e2e test callbacks)
Don't create queries outside models, the query description should be inside the model class.
Don't hardcode fields inside models. the same method can be used for different purposes, using different fields.
Prefer to create REST endpoints over Meteor methods
Prefer call REST endpoints over Meteor methods when both are available
v1 REST endpoints should follow the following pattern:
Import the HTML file from it's sibling JS/TS file
Before submitting a PR you should get no errors on
To check your files run:
meteor npm run lint
There are 2 types of tests we run on Rocket.Chat, Unit tests and End to End tests. The major difference is that End to End tests require a Rocket.Chat instance running to execute the API and UI checks.
First, you need to run a Rocket.Chat server on Test Mode and on an Empty Database:
# Running with a local mongodb databaseMONGO_URL=mongodb://localhost/empty MONGO_OPLOG_URL=mongodb://localhost/local TEST_MODE=true meteor
# Running with a local mongodb database but cleaning it beforemongo --eval "db.dropDatabase()" empty && MONGO_URL=mongodb://localhost/empty MONGO_OPLOG_URL=mongodb://localhost/local TEST_MODE=true meteor
Now you can run the tests:
meteor npm test
Unit tests are simpler to set up and run. They do not require a working Rocket.Chat instance.
meteor npm run testunit
It's possible to run on watch mode as well:
meteor npm run testunit-watch
It's important to run the lint and tests before push your code or submit a Pull Request, otherwise, your contribution may fail quickly on the CI. Reviewers are forced to demand fixes and the review of your contribution will be further delayed.
Rocket.Chat uses husky to run the lint and unit tests before proceeding to the code push process, so you may notice a delay when pushing your code to your repository.
It is very important to note that we use PR titles when creating our changelog. Keep this in mind when you title your PR. Make sure the title makes sense to a person reading a releases' changelog!
Keep your PR's title as short and concise as possible, use PR's description section, which you can find in the PR's template, to provide more details into the changelog.
Good titles require thinking from a user's point of view. Don't get technical and talk code or architecture. What is the actual user-facing feature or the bug fixed? For example:
[NEW] Allow search permissions and settings by name instead of only ID
Even it's being something new in the code the users already expect the filter to filter by what they see (translations), a better one would be:
[FIX] Permissions' search doesn't filter base on presented translation, only on internal ids
You can use several tags do describe your PR, i.e.:
[NEW], etc. You can use the descriptions below to better understand the meaning of each one, and decide which one you should use:
When adding a new feature that is important to the end-user
Do not start repeating the section (
Add ... or
New ...) Always describe what's being fixed, improved or added and not how it was fixed, improved or added.
Example of bad PR titles:
[NEW] Add ability to set tags in the Omnichannel room closing dialog[NEW] Adds ability for Rocket.Chat Apps to create discussions[NEW] Add MMS support to Voxtelesys[NEW] Add Color variable to left sidebar
Example of good PR titles:
[NEW] Ability to set tags in the Omnichannel room closing dialog[NEW] Ability for Rocket.Chat Apps to create discussions[NEW] MMS support to Voxtelesys[NEW] Color variable to left sidebar
When fixing something not working or behaving wrong from the end-user perspective
Always describe what's being fixed and not how it was fixed.
Example of a bad PR title:
[FIX] Add Content-Type for public files with JWT
Example of a good PR title:
[FIX] Missing Content-Type header for public files with JWT
When a change enhances a not buggy behavior. When in doubt if it's an Improve or Fix prefer to use Fix.
Always describe what's being improved and not how it was improved.
Example of good PR title:
[IMPROVE] Displays Nothing found on admin sidebar when search returns nothing
When the changes affect a working feature
When the API contract (data structure and endpoints) are limited, expanded as required or removed
When the business logic (permissions and roles) are limited, expanded (without migration) or removed
When the change limits (format, size, etc) or removes the ability to read or change the data (when the limitation was not caused by the back-end)
When changes are made during release candidate cycle to in order to add something missing or fix something broken during the last development cycle and not published to a final release yet.
Example of good PR titles:
Regression: Fix not being able to mark room as readRegression: Add missing field to `users` endpoint
Use a second tag to group entries on the changelog. We currently use it only for Enterprise and Apps items, but we are going to expand its usage soon. If you're not sure about which one to use, you most likely do not need to use a second tag. We're still coming up with a pattern for it.
For those PRs that aren't important for the end-user, we are working on a better pattern, but for now please use the same tags, use them without the brackets and in camel case:
Fix: Missing Content-Type header for public files with JWT
All those PRs will be grouped under the
Minor changes section which is collapsed, so users can expand it to check for those minor things but they are not visible directly on the changelog.
Never expose unnecessary data to the APIs' responses
Always check for permissions or create new ones when you must expose sensitive data
Never provide new APIs without rate limiters
Always escape the user's input when rendering data
Always limit the user's input size on the server-side
Always execute the validations on the server-side even when executing on the client-side as well
Prefer to inform the fields you want, and only the necessary ones, when querying data from the database over query the full documents
Limit the number of returned records to a reasonable value
Check if the query is using indexes, if it's not, create new indexes
Prefer queues over long executions
Create new metrics to measure things whenever possible
Cache data and returns whenever possible
To have your contribution accepted you must sign our Contributor License Agreement. In case you submit a Pull Request before sign the CLA GitHub will alert you with a new comment asking you to sign and will block the Pull Request from be merged by us.
Please review and sign our CLA at https://cla-assistant.io/RocketChat/Rocket.Chat