We welcome any contribution to odata2ts:
- bug reports
- feature requests
- pull requests
- suggestions
- usage questions
- ...
We're using Github Issues and Pull Requests as main line of communication.
We expect that you've read the odata2ts documentation. A lot of work went into it and it should be your prime source to get the information you need.
However, as soon as the documentation does not live up to this standard (you don't find the documentation or don't get the answer you actually need, etc.), then by all means open an issue on Github. Please feel encouraged to do so, because it indicates a shortcoming of the documentation.
Also, if your OData service doesn't behave according to the specification, please create an issue as well.
The world's not perfect and odata2ts should cope with that
(see issue #144 for an example).
Currently, there's no template in place for creating issues. Use the closed issues as examples, they were all relevant and pretty well written.
So, you have read the relevant documentation parts and skimmed through the existing issues, then go for it.
- Node.js
- Yarn
Clone the repo.
yarn install
yarn buildTo run the unit tests of all modules:
yarn testEach module should come with its own set of unit tests in folder test.
To execute only unit tests of a specific module, change to the module in question and call yarn test from there.
Modules without unit tests:
- modules which represent APIs / consist only of TypeScript types, e.g.
odata-coreorodata-client-api - axios-odata-client
- jquery-odata-client
By calling yarn int-test from the root folder all integration tests are executed.
You need to start one server first though:
yarn start-capWhile the CAP server is running, you can start the integration tests from a different terminal:
yarn int-testModules which come with integration tests store them in folder int-test.
You execute them by changing to the module and calling yarn int-test from there.
Nearly all integration tests are to be found in the example projects.
We love conventional commits and use them to drive
our semantic versioning. Try to adhere to these conventions. odata2ts uses the following types:
fix: Bug fixes, fixing typos, etc.feat: New featureschore:doc: Documentation changesrefactor: Refactoring codebuild: changes to the build process
We will probably squash your commits before merging them into the main branch.
So also adhere to conventional commits within the title of your pull request.
Examples:
- fix(odata-query-builder): typo in README
- feat: my new feature
- ...
Only available for maintainers.
yarn release