feat: 0.2.0

Author: twlite

.editorconfig

@@ -0,0 +1,10 @@
+root = true
+
+[*]
+end_of_line = lf
+insert_final_newline = true
+
+[*.{js,json,yml}]
+charset = utf-8
+indent_style = space
+indent_size = 2

.gitattributes

@@ -0,0 +1,4 @@
+/.yarn/**            linguist-vendored
+/.yarn/releases/*    binary
+/.yarn/plugins/**/*  binary
+/.pnp.*              binary linguist-generated

.gitignore

@@ -1,2 +1,17 @@
-dist/
-node_modules/
+.yarn/*
+!.yarn/patches
+!.yarn/plugins
+!.yarn/releases
+!.yarn/sdks
+!.yarn/versions
+
+# Swap the comments on the following lines if you wish to use zero-installs
+# In that case, don't forget to run `yarn config set enableGlobalCache false`!
+# Documentation here: https://yarnpkg.com/features/zero-installs
+
+#!.yarn/cache
+.pnp.*
+
+node_modules
+
+dist

.vscode/settings.json

@@ -0,0 +1,3 @@
+{
+  "typescript.tsdk": "node_modules\\typescript\\lib"
+}

.yarnrc.yml

@@ -0,0 +1 @@
+nodeLinker: node-modules

CODE_OF_CONDUCT.md

@@ -0,0 +1,128 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at [email protected]
+.
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior,  harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.0, available at
+https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
+
+Community Impact Guidelines were inspired by [Mozilla's code of conduct
+enforcement ladder](https://github.com/mozilla/diversity).
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see the FAQ at
+https://www.contributor-covenant.org/faq. Translations are available at
+https://www.contributor-covenant.org/translations.

CONTRIBUTING.md

@@ -0,0 +1,100 @@
+# Contributing
+
+Thank you for showing interests in contributing to this project. Please follow this guide before contributing to this project.
+
+## Don't know where to start?
+
+If you dont know from where to start, check the issue tracker.
+
+## Check for existing PRs
+
+Before making a pull request, make sure to check if someone else has already made a PR for that specific topic. Avoid duplicated PRs.
+
+## Commits
+
+Follow [conventional commits](https://www.conventionalcommits.org/en) format while committing. Conventional commit dovetails with semver, by describing the features, fixes, and breaking changes made in commit messages. The following specification is adapted from [conventionalcommits.org](https://www.conventionalcommits.org/en).
+
+The commit message should be structured as follows:
+
+```text
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer]
+```
+
+##### The commit contains the following structural elements, to communicate intent to the consumers of your library:
+
+1. `fix`: a commit of the type fix patches a bug in your codebase (this correlates with `PATCH` in semantic versioning).
+2. `feat`: a commit of the type feat introduces a new feature to the codebase (this correlates with `MINOR` in semantic versioning).
+3. `BREAKING CHANGE`: a commit that has the text `BREAKING CHANGE`: at the beginning of its optional body or footer section introduces a breaking API change (correlating with MAJOR in semantic versioning). A `BREAKING CHANGE` can be part of commits of any type.
+4. Others: commit types other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://npm.im/@commitlint/config-conventional) (based on the [Angular convention](https://github.com/angular/angular/blob/68a6a07/CONTRIBUTING.md#commit)) recommends `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
+
+### Examples
+#### Commit message with description and breaking change in body
+
+```text
+feat: allow provided config object to extend other configs
+
+BREAKING CHANGE: `extends` key in config file is now used for extending other config files
+```
+
+#### Commit message with optional `!` to draw attention to breaking change
+
+```text
+chore!: drop Node 6 from testing matrix
+
+BREAKING CHANGE: dropping Node 6 which hits end of life in April
+```
+
+#### Commit message with no body
+
+```text
+docs: correct spelling of CHANGELOG
+```
+
+#### Commit message with scope
+
+```text
+feat(lang): add polish language
+```
+
+#### Commit message for a fix using an (optional) issue number.
+
+```text
+fix: correct minor typos in code
+
+see the issue for details on the typos fixed
+
+closes issue #12
+```
+
+### Specification
+
+The key words `“MUST”`, `“MUST NOT”`, `“REQUIRED”`, `“SHALL”`, `“SHALL NOT”`, `“SHOULD”`, `“SHOULD NOT”`, `“RECOMMENDED”`, `“MAY”`, and `“OPTIONAL”` in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
+
+1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed by an OPTIONAL scope, and a REQUIRED terminal colon and space.
+2. The type `feat` MUST be used when a commit adds a new feature to your application or library.
+3. The type `fix` MUST be used when a commit represents a bug fix for your application.
+4. A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., `fix(parser):`
+5. A description MUST immediately follow the space after the type/scope prefix. The description is a short summary of the code changes, e.g., `fix: array parsing issue when multiple spaces were contained in string`.
+6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
+7. A footer of one or more lines MAY be provided one blank line after the body. The footer MUST contain meta-information about the commit, e.g., related pull-requests, reviewers, breaking changes, with one piece of meta-information per-line.
+8. Breaking changes MUST be indicated at the very beginning of the body section, or at the beginning of a line in the footer section. A breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon and a space.
+9. A description MUST be provided after the `BREAKING CHANGE:`, describing what has changed about the API, e.g., `BREAKING CHANGE: environment variables now take precedence over config files`.
+10. Types other than `feat` and `fix` MAY be used in your commit messages.
+11. The units of information that make up conventional commits MUST NOT be treated as case sensitive by implementors, with the exception of `BREAKING CHANGE` which MUST be uppercase.
+12. A `!` MAY be appended prior to the `:` in the type/scope prefix, to further draw attention to breaking changes. `BREAKING CHANGE: description` MUST also be included in the body or footer, along with the `!` in the prefix.
+
+## Formatting, Linting, Testing
+
+Make sure to properly format the source code, check for linter errors and test the code before pushing.
+
+## File Names
+
+1. Use `PascalCase` format if the file belongs to a class. Ex: `NobuBrowser.ts`, `ProtocolService.ts`, etc.
+2. Use `camelCase` format for the files that belong to functions. Ex: `contextMenu`, `appMenu`, etc.
+3. Use `lowercase` format for other cases.
+
+> 🎉 Happy coding!

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) Neplex Technologies
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

README.md

@@ -1,22 +1,35 @@
-# `micro-docgen`
+# micro-docgen
 
-Simple documentation generator for TypeScript projects.
+TypeScript documentation generator on steroids 💉. MicroDocgen is built on top of typedoc to leverage its power and add more features.
 
-> ⚠️ **WIP!! Currently only supports class & function serialization**
+## TODO
 
-# Example
+-   Static site generation
+-   More options
 
-```js
-const { Docgen } = require('micro-docgen');
-const docgen = new Docgen();
-const fs = require('fs');
+## Installation
+
+```sh
+$ npm install micro-docgen
+```
 
-// add source file(s)
-docgen.addFiles('./src/*.ts');
+## Usage
 
-// Generate json
-const documentation = docgen.generate();
+```js
+import { createDocumentation } from 'micro-docgen';
 
-// write the output to docs.json
-fs.writeFileSync('./docs.json', JSON.stringify(documentation, null, '\t'));
+await createDocumentation({
+    // source files
+    input: ['src'],
+    // output directory
+    output: 'docs',
+    // tsconfig path
+    tsconfigPath: './tsconfig.json',
+    // to generate markdown files
+    markdown: true,
+    // to generate json file
+    jsonName: 'docs.json',
+    // include custom files such as readme
+    custom: [...]
+});
 ```

docs/classes/AbstractSerializer.md

@@ -0,0 +1,17 @@
+## AbstractSerializer
+
+```typescript
+new AbstractSerializer(declaration);
+```
+
+| Parameter   | Type                  | Optional |
+| ----------- | --------------------- | -------- |
+| declaration | DeclarationReflection | ❌       |
+
+## Properties
+
+### public declaration: any
+
+## Methods
+
+### public serialize(): [void](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/undefined)