cddl 0.8.1 β†’ 0.8.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "cddl",
3
- "version": "0.8.1",
3
+ "version": "0.8.3",
4
4
  "description": "Concise data definition language (RFC 8610) implementation and JSON validator in Node.js",
5
5
  "author": "Christian Bromann <mail@bromann.dev>",
6
6
  "license": "MIT",
@@ -17,6 +17,7 @@
17
17
  },
18
18
  "type": "module",
19
19
  "exports": "./build/index.js",
20
+ "types": "./build/index.d.ts",
20
21
  "bin": {
21
22
  "cddl": "./bin/cddl.js"
22
23
  },
@@ -34,12 +35,12 @@
34
35
  },
35
36
  "devDependencies": {
36
37
  "@types/jest": "^29.4.0",
37
- "@types/node": "^18.14.6",
38
+ "@types/node": "^20.2.3",
38
39
  "@vitest/coverage-c8": "^0.29.2",
39
40
  "npm-run-all": "^4.1.5",
40
41
  "release-it": "^15.7.0",
41
- "typescript": "^4.9.5",
42
- "vitest": "^0.29.2"
42
+ "typescript": "^5.0.4",
43
+ "vitest": "^0.31.1"
43
44
  },
44
45
  "dependencies": {
45
46
  "yargs": "^17.7.1"
package/.editorconfig DELETED
@@ -1,18 +0,0 @@
1
- # EditorConfig helps developers define and maintain consistent
2
- # coding styles between different editors and IDEs
3
- # editorconfig.org
4
-
5
- root = true
6
-
7
- [*]
8
-
9
- indent_style = space
10
- indent_size = 4
11
-
12
- end_of_line = lf
13
- charset = utf-8
14
- trim_trailing_whitespace = true
15
- insert_final_newline = true
16
-
17
- [{.travis.yml,**/*.json,.github/**/*.yml}]
18
- indent_size = 2
package/.nvmrc DELETED
@@ -1 +0,0 @@
1
- v18.15.0
package/CONTRIBUTING.md DELETED
@@ -1,82 +0,0 @@
1
- # Contributing to the `cddl` NPM package
2
-
3
- **Thank you for your interest in the `cddl` NPM package. Your contributions are highly welcome.**
4
-
5
- There are multiple ways of getting involved:
6
-
7
- - [Setup Project](#setup-project)
8
- - [Report a bug](#report-a-bug)
9
- - [Suggest a feature](#suggest-a-feature)
10
- - [Contribute code](#contribute-code)
11
-
12
- Below are a few guidelines we would like you to follow.
13
- If you need help, please reach out to us by opening an issue.
14
-
15
- ## Setup Project
16
-
17
- To setup the project you first have to clone the code base:
18
-
19
- ```sh
20
- $ git clone git@github.com:christian-bromann/cddl.git
21
- $ cd cddl
22
- ```
23
-
24
- Then install the project dependencies:
25
-
26
- ```sh
27
- $ npm install
28
- ```
29
-
30
- Before we start working on the code, let's make sure all tests are passing:
31
-
32
- ```sh
33
- $ npm test
34
- ```
35
-
36
- If everything is green, you are good to go πŸ‘
37
-
38
- ## Report a bug
39
- Reporting bugs is one of the best ways to contribute. Before creating a bug report, please check that an [issue](/issues) reporting the same problem does not already exist. If there is such an issue, you may add your information as a comment.
40
-
41
- To report a new bug you should open an issue that summarizes the bug and set the label to "bug".
42
-
43
- If you want to provide a fix along with your bug report: That is great! In this case please send us a pull request as described in section [Contribute Code](#contribute-code).
44
-
45
- ## Suggest a feature
46
- To request a new feature you should open an [issue](../../issues/new) and summarize the desired functionality and its use case. Set the issue label to "feature".
47
-
48
- ## Contribute code
49
- This is an outline of what the workflow for code contributions looks like
50
-
51
- - Check the list of open [issues](../../issues). Either assign an existing issue to yourself, or
52
- create a new one that you would like work on and discuss your ideas and use cases.
53
-
54
- It is always best to discuss your plans beforehand, to ensure that your contribution is in line with our goals.
55
-
56
- - Fork the repository on GitHub
57
- - Create a topic branch from where you want to base your work. This is usually master.
58
- - Open a new pull request, label it `work in progress` and outline what you will be contributing
59
- - Make commits of logical units.
60
- - Make sure you sign-off on your commits `git commit -s -m "adding X to change Y"`
61
- - Write good commit messages (see below).
62
- - Push your changes to a topic branch in your fork of the repository.
63
- - As you push your changes, update the pull request with new infomation and tasks as you complete them
64
- - Project maintainers might comment on your work as you progress
65
- - When you are done, remove the `work in progess` label and ping the maintainers for a review
66
- - Your pull request must receive a :thumbsup: from two [maintainers](MAINTAINERS)
67
-
68
- Thanks for your contributions!
69
-
70
- ### Commit messages
71
- Your commit messages ideally can answer two questions: what changed and why. The subject line should feature the β€œwhat” and the body of the commit should describe the β€œwhy”.
72
-
73
- When creating a pull request, its description should reference the corresponding issue id.
74
-
75
- ### Sign your work / Developer certificate of origin
76
- All contributions (including pull requests) must agree to the Developer Certificate of Origin (DCO) version 1.1. This is exactly the same one created and used by the Linux kernel developers and posted on http://developercertificate.org/. This is a developer's certification that he or she has the right to submit the patch for inclusion into the project. Simply submitting a contribution implies this agreement, however, please include a "Signed-off-by" tag in every patch (this tag is a conventional way to confirm that you agree to the DCO) - you can automate this with a [Git hook](https://stackoverflow.com/questions/15015894/git-add-signed-off-by-line-using-format-signoff-not-working)
77
-
78
- ```
79
- git commit -s -m "adding X to change Y"
80
- ```
81
-
82
- **Have fun, and happy hacking!**