Please note! The github issue tracker should only be used for feature requests and bugs with a clear description of the issue and the expected behaviour (see below). All questions belong on Slack, StackOverflow or Google groups.
Issues are always very welcome - after all, they are a big part of making sequelize better. However, there are a couple of things you can do to make the lives of the developers much, much easier:
- What you are doing?
- Post a minimal code sample that reproduces the issue, including models and associations
- What do you expect to happen?
- What is actually happening?
- Which dialect you are using (postgres, mysql etc)?
- Which sequelize version you are using?
When you post code, please use Github flavored markdown, in order to get proper syntax highlighting!
If you can even provide a pull request with a failing unit test, we will love you long time! Plus your issue will likely be fixed much faster.
We're glad to get pull request if any functionality is missing or something is buggy. However, there are a couple of things you can do to make life easier for the maintainers:
- Explain the issue that your PR is solving - or link to an existing issue
- Make sure that all existing tests pass
- Make sure you followed coding guidelines
- Add some tests for your new functionality or a test exhibiting the bug you are solving. Ideally all new tests should not pass without your changes.
- Use promise style in all new tests. Specifically this means:
- don't use
EventEmitter
,QueryChainer
or thesuccess
,done
anderror
events - don't use nested callbacks (use Promise.bind to maintain context in promise chains)
- don't use a done callback in your test, just return the promise chain.
- don't use
- Small bugfixes and direct backports to the 1.7 branch are accepted without tests.
- Use promise style in all new tests. Specifically this means:
- If you are adding to / changing the public API, remember to add API docs, in the form of JSDoc style comments. See section 4a for the specifics.
- Add an entry to the changelog, with a link to the issue you are solving
Still interested? Coolio! Here is how to get started:
Here comes a little surprise: You need Node.JS.
Just "cd" into sequelize directory and run npm install
, see an example below:
$ cd path/to/sequelize
$ npm install
For MySQL and PostgreSQL you'll need to create a DB called sequelize_test
.
For MySQL this would look like this:
$ echo "CREATE DATABASE sequelize_test;" | mysql -uroot
CLEVER NOTE: by default, your local MySQL install must be with username root
without password. If you want to customize that, you can set the environment variables SEQ_DB
, SEQ_USER
, SEQ_PW
, SEQ_HOST
and SEQ_PORT
.
For Postgres, creating the database and (optionally) adding the test user this would look like:
$ psql
# create database sequelize_test;
# create user postgres with superuser;
AND ONE LAST THING: Once npm install
worked for you (see below), you'll
get SQLite tests for free :)
Makes sure docker
and docker-compose
are installed.
If running on Mac OSX, install Docker for Mac.
Then simply run:
npm run test-docker
And once in a while you might want to run:
npm run build-docker
To rebuild the image (in case of changed dependencies or similar).
If sequelize is unable to connect to mysql you might want to try running sudo docker-compose up
in a second terminal window.
All tests are located in the test
folder (which contains the
lovely Mocha tests).
$ npm run test-all || test-mysql || test-sqlite || test-mssql || test-postgres || test-postgres-native
$ # alternatively you can pass database credentials with $variables when testing
$ DIALECT=dialect SEQ_DB=database SEQ_USER=user SEQ_PW=password npm test
This step only applies if you have actually changed something in the documentation. Please read Documentation Contribution Guidelines first.
To generate documentation for the sequelize.js
file, run (in the sequelize dir)
$ npm run docs
The generated documentation will be placed in docs/tmp.md
.
Just commit and send your pull request. Happy hacking and thank you for contributing.
Have a look at our .jshintrc file for the specifics. As part of the test process, all files will be linted, and your PR will not be accepted if it does not pass linting.
Use spaces when defining functions.
function(arg1, arg2, arg3) {
return 1;
}
Use spaces for if statements.
if (condition) {
// do something
} else {
// something else
}
var num = 1
, user = new User()
, date = new Date();
Yes
- Ensure that latest build on master is green
- Ensure your local code is up to date (
git pull origin master
) npm version patch|minor|major
(see Semantic Versioning)- Update changelog to match version number, commit changelog
git push --tags origin master
npm publish .
- Copy changelog for version to release notes for version on github