|
1
|
Filing tickets against loglevel
|
|
2
|
===============================
|
|
3
|
|
|
4
|
If you'd like to file a bug or a feature request for loglevel, the best option is to [open an issue on Github](https://github.com/pimterry/loglevel/issues/new).
|
|
5
|
|
|
6
|
If you're filing a feature request, please remember:
|
|
7
|
|
|
8
|
* Feature requests significantly expanding the scope of loglevel outside the description in [the readme](https://github.com/pimterry/loglevel/blob/master/README.md) will probably be rejected.
|
|
9
|
* Features that can't be meaningfully implemented in a cross-environment compatible manner won't be implemented.
|
|
10
|
* Please check the previously opened issues to see if somebody else has suggested it first.
|
|
11
|
* Consider submitting a pull request to add the feature instead, if you're confident it fits within the above
|
|
12
|
|
|
13
|
If you're filing a bug, please remember:
|
|
14
|
|
|
15
|
* To provide detailed steps to reproduce the behaviour
|
|
16
|
* If possible, provide a Jasmine test which reproduces the behaviour
|
|
17
|
* Please specify the exact details of the environment in which it fails: OS + Environment (i.e. Browser or Node) + version
|
|
18
|
* Consider submitting a pull request to fix the bug instead
|
|
19
|
|
|
20
|
Helping develop loglevel
|
|
21
|
================================
|
|
22
|
|
|
23
|
If you'd like to help develop loglevel further, please submit a pull request! I'm very keen to improve loglevel further, and good pull requests will be enthusiastically merged.
|
|
24
|
|
|
25
|
Before submitting a pull request to fix a bug or add a new feature, please check the lists above to ensure it'll be accepted. Browser compatibility is particularly important here; if you add a feature or fix a bug which breaks things on other browsers it will not be merged, no matter how awesome it may be.
|
|
26
|
|
|
27
|
To be more specific, before submitting your pull request please ensure:
|
|
28
|
|
|
29
|
* You haven't broken the existing test suite in any obvious browsers (at least check latest IE/FF/Chrome - automatic saucelabs tests for this are coming soon too)
|
|
30
|
* You've added relevant tests for the bug you're fixing/the new feature you're adding/etc, which pass in all the relevant browsers
|
|
31
|
* JSHint is happy with your new code
|
|
32
|
* You've updated the API docs (in README.md) to detail any changes you've made to the public interface
|
|
33
|
* Your change is backward compatible (or you've explicitly said if it's not; this isn't great, but will be considered)
|
|
34
|
* You haven't changed any files in dist/ (these are auto-generated, and should only be changed on release)
|
|
35
|
|
|
36
|
Project structure
|
|
37
|
-----------------
|
|
38
|
|
|
39
|
The core project code is all in lib/loglevel.js, and this should be the only file you need to touch for functional changes themselves.
|
|
40
|
|
|
41
|
The released code is in dist/*.js, and should not be touched by anything except releases
|
|
42
|
|
|
43
|
The test suite is entirely in test/*.js:
|
|
44
|
|
|
45
|
* Every file ending in '-test.js' is a unit test, is written in RequireJS, and should pass in any environment
|
|
46
|
* global-integration.js and node-integration.js are quick integration smoke tests for node and for browser global usage
|
|
47
|
* test-helpers.js contains some test utilities
|
|
48
|
* manual-test.html is a test page which includes the current loglevel build, so you can manually check it works in a given browser
|
|
49
|
|
|
50
|
How to make your change and submit it
|
|
51
|
-------------------------------------
|
|
52
|
|
|
53
|
1. Fork loglevel
|
|
54
|
2. Clone your fork locally
|
|
55
|
3. Create a branch from master for your change
|
|
56
|
4. Write some tests in /test for your change, as relevant
|
|
57
|
5. Make your code changes in /lib/loglevel.js
|
|
58
|
6. Check your code all passes (run `grunt`) - if you have any issues try running `grunt jasmine:requirejs:src:build` (or a different test build instead of 'requirejs': see the jasmine config in Gruntfile.js) and debugging the generated _SpecRunner.html in a browser
|
|
59
|
7. Commit your changes
|
|
60
|
8. Open a pull request back to master in loglevel
|
|
61
|
|
|
62
|
Reporting security issues
|
|
63
|
-------------------------
|
|
64
|
|
|
65
|
Tidelift acts as the security contact for loglevel. Issues can be reported to security@tidelift.com, see https://tidelift.com/security for more details.
|