Skip to content

Commit 2a84c8d

Browse files
da730da730
committed
feat: add scripts
1 parent ad563b0 commit 2a84c8d

File tree

145 files changed

+112510
-15
lines changed

Some content is hidden

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

145 files changed

+112510
-15
lines changed

‎.editorconfig

+9
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
root = true
2+
3+
[*]
4+
charset = utf-8
5+
indent_style = space
6+
indent_size = 2
7+
end_of_line = lf
8+
insert_final_newline = true
9+
trim_trailing_whitespace = true

‎.eslintignore

+1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
tools/typescript-json-schema

‎.gitattributes

+14
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
# Don't allow people to merge changes to these generated files, because the result
2+
# may be invalid. You need to run "rush update" again.
3+
pnpm-lock.yaml merge=text
4+
shrinkwrap.yaml merge=binary
5+
npm-shrinkwrap.json merge=binary
6+
yarn.lock merge=binary
7+
8+
# Rush's JSON config files use JavaScript-style code comments. The rule below prevents pedantic
9+
# syntax highlighters such as GitHub's from highlighting these comments as errors. Your text editor
10+
# may also require a special configuration to allow comments in JSON.
11+
#
12+
# For more information, see this issue: https://github.com/microsoft/rushstack/issues/1088
13+
#
14+
*.json linguist-language=JSON-with-Comments

‎.gitignore

+103
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
# Logs
2+
*.log
3+
npm-debug.log*
4+
yarn-debug.log*
5+
yarn-error.log*
6+
7+
# Runtime data
8+
*.pid
9+
*.seed
10+
*.pid.lock
11+
12+
# Directory for instrumented libs generated by jscoverage/JSCover
13+
lib-cov
14+
15+
# Coverage directory used by tools like istanbul
16+
coverage
17+
18+
# nyc test coverage
19+
.nyc_output
20+
21+
# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
22+
.grunt
23+
24+
# Bower dependency directory (https://bower.io/)
25+
bower_components
26+
27+
# node-waf configuration
28+
.lock-wscript
29+
30+
# Compiled binary addons (https://nodejs.org/api/addons.html)
31+
build/Release
32+
output
33+
dist
34+
esm
35+
es
36+
cjs
37+
build
38+
build-es5
39+
*.zip
40+
41+
42+
*.zip
43+
stats.html
44+
report.html
45+
46+
coverage/
47+
48+
*.local.ts
49+
50+
# Dependency directories
51+
node_modules/
52+
jspm_packages/
53+
54+
# Optional npm cache directory
55+
.npm
56+
57+
# Optional eslint cache
58+
.eslintcache
59+
60+
# Optional REPL history
61+
.node_repl_history
62+
63+
# Output of 'npm pack'
64+
*.tgz
65+
66+
# Yarn Integrity file
67+
.yarn-integrity
68+
69+
# dotenv environment variables file
70+
.env
71+
72+
# next.js build output
73+
.next
74+
75+
# OS X temporary files
76+
.DS_Store
77+
78+
# IntelliJ IDEA project files; if you want to commit IntelliJ settings, this recipe may be helpful:
79+
# https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
80+
.idea/
81+
*.iml
82+
83+
# Rush temporary files
84+
common/deploy/
85+
common/temp/
86+
common/autoinstallers/*/.npmrc
87+
**/.rush/temp/
88+
89+
# Heft temporary files
90+
.heft
91+
92+
# build
93+
.rollup.cache/
94+
tsconfig.tsbuildinfo
95+
96+
# git-hook
97+
common/scripts/pre-commit
98+
99+
# generated documents
100+
docs/public/documents
101+
102+
# env files
103+
.env.local

‎.lintstagedrc

+3
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
{
2+
"{packages,tools}/**/*.{ts,tsx}": ["eslint --color --fix --quiet", "prettier --write --ignore-unknown"]
3+
}

‎.prettierignore

+29
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
# https://prettier.io/docs/en/ignore.html
2+
#-------------------------------------------------------------------------------------------------------------------
3+
# Keep this section in sync with .gitignore
4+
#-------------------------------------------------------------------------------------------------------------------
5+
6+
👋 (copy + paste your .gitignore file contents here) 👋
7+
8+
#-------------------------------------------------------------------------------------------------------------------
9+
# Prettier-specific overrides
10+
#-------------------------------------------------------------------------------------------------------------------
11+
12+
# Rush files
13+
common/changes/
14+
common/scripts/
15+
common/config/
16+
CHANGELOG.*
17+
18+
# Package manager files
19+
pnpm-lock.yaml
20+
yarn.lock
21+
package-lock.json
22+
shrinkwrap.json
23+
24+
# Build outputs
25+
dist
26+
lib
27+
**/*.min.js
28+
tools/typescript-json-schema
29+

‎.prettierrc.js

+15
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
// Documentation for this file: https://prettier.io/en/configuration.html
2+
module.exports = {
3+
"printWidth": 120,
4+
"tabWidth": 2,
5+
"useTabs": false,
6+
"semi": true,
7+
"singleQuote": true,
8+
"quoteProps": "as-needed",
9+
"trailingComma": "none",
10+
"bracketSpacing": true,
11+
"arrowParens": "avoid",
12+
"proseWrap": "preserve",
13+
"htmlWhitespaceSensitivity": "css",
14+
"endOfLine": "lf"
15+
};

‎CODE_OF_CONDUCT.md

+47
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
# Contributor Covenant Code of Conduct
2+
3+
## Our Pledge
4+
5+
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, 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.
6+
7+
## Our Standards
8+
9+
Examples of behavior that contributes to creating a positive environment include:
10+
11+
- Using welcoming and inclusive language
12+
- Being respectful of differing viewpoints and experiences
13+
- Gracefully accepting constructive criticism
14+
- Focusing on what is best for the community
15+
- Showing empathy towards other community members
16+
17+
Examples of unacceptable behavior by participants include:
18+
19+
- The use of sexualized language or imagery and unwelcome sexual attention or advances
20+
- Trolling, insulting/derogatory comments, and personal or political attacks
21+
- Public or private harassment
22+
- Publishing others' private information, such as a physical or electronic address, without explicit permission
23+
- Other conduct which could reasonably be considered inappropriate in a professional setting
24+
25+
## Our Responsibilities
26+
27+
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
28+
29+
Project maintainers 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, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
30+
31+
## Scope
32+
33+
This Code of Conduct applies within all project spaces, and it also applies when an individual is representing the project or its community in public spaces. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
34+
35+
## Enforcement
36+
37+
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at https://github.com/VisActor. 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.
38+
39+
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.
40+
41+
## Attribution
42+
43+
This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 1.4,
44+
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
45+
46+
For answers to common questions about this code of conduct, see
47+
https://www.contributor-covenant.org/faq

‎CONTRIBUTING.md

+70
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
# Contributing
2+
3+
## Code of Conduct
4+
5+
We has adopted [the Contributor Covenant](CODE_OF_CONDUCT.md) as our Code of Conduct, and we expect project participants to adhere to it. Please read the full text so that you can understand what actions will and will not be tolerated.
6+
7+
## Open Development
8+
9+
All work on VChart happens directly on GitHub. Both core team members and external contributors send pull requests which go through the same review process.
10+
11+
## Semantic Versioning
12+
13+
VChart follows [semantic versioning](https://semver.org/). We release patch versions for critical bugfixes, minor versions for new features or non-essential changes, and major versions for any breaking changes. When we make breaking changes, we also introduce deprecation warnings in a minor version so that our users learn about the upcoming changes and migrate their code in advance.
14+
15+
Every significant change is documented in the changelog file.
16+
17+
## Branch Organization
18+
19+
Submit all changes directly to the main branch. We don’t use separate branches for development or for upcoming releases. We do our best to keep main in good shape, with all tests passing.
20+
21+
Code that lands in main must be compatible with the latest stable release. It may contain additional features, but no breaking changes. We should be able to release a new minor version from the tip of main at any time.
22+
23+
## Bugs
24+
25+
We are using [GitHub Issues](https://github.com/VisActor/VChart/issues) for our public bugs. We keep a close eye on this and try to make it clear when we have an internal fix in progress. Before filing a new task, try to make sure your problem doesn’t already exist.
26+
27+
We have already prepared issue templates for bug reports and feature requests. If you want to fire an issue, just enter the [New issue](https://github.com/VisActor/VChart/issues/new/choose) page and select either of them to get started. The best way to get your bug fixed is by using our issue template and provide reproduction steps with this [template](https://github.com/VisActor/VChart/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+).
28+
29+
## Proposing a Change
30+
31+
If you intend to change the public API, or make any non-trivial changes to the implementation, we recommend filing an issue, or just enter the [New issue](https://github.com/VisActor/VChart/issues/new/choose) page and select either of them to get started.
32+
33+
If you’re only fixing a bug, it’s fine to submit a pull request right away but we still recommend to file an issue detailing what you’re fixing. This is helpful in case we don’t accept that specific fix but want to keep track of the issue.
34+
35+
## Your First Pull Request
36+
37+
Working on your first Pull Request? You can learn how from this free video series:[How to Contribute to an Open Source Project on GitHub](https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github)
38+
39+
To help you get your feet wet and get you familiar with our contribution process, we have a list of [good first issues](https://github.com/VisActor/VChart/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) that contain bugs that have a relatively limited scope. This is a great place to get started.
40+
41+
If you decide to fix an issue, please be sure to check the comment thread in case somebody is already working on a fix. If nobody is working on it at the moment, please leave a comment stating that you intend to work on it so other people don’t accidentally duplicate your effort.
42+
43+
If somebody claims an issue but doesn’t follow up for more than two weeks, it’s fine to take it over but you should still leave a comment.
44+
45+
### Sending a Pull Request
46+
47+
The core team is monitoring for pull requests. We will review your pull request and either merge it, request changes to it, or close it with an explanation. We’ll do our best to provide updates and feedback throughout the process.
48+
49+
**Before submitting a pull request**, please make sure the following is done:
50+
51+
1. Fork the [repository]([email protected]:VisActor/VChart.git) and create your branch from `main`.
52+
2. (If rush has been install, just go to step 3) global install [@microsoft/rush](https://rushjs.io/pages/intro/get_started/)：`npm i --global @microsoft/rush`.
53+
3. Run `rush update` in the repository root.
54+
4. If you’ve fixed a bug or added code that should be tested, add tests!
55+
5. Ensure the test suite passes (`rush test`).
56+
6. If you've modified sources code(The code in `src/` folder), make sure you've run `rush change`, and commit the rush changelog in `common/changes`.
57+
7. Run `rush compile` for typescript check. Tip: we will also do this check in github workflow.
58+
59+
## Development Workflow
60+
61+
After cloning VChart, run `rush update` to fetch its dependencies. Then, you can run several commands:
62+
63+
1. `rush start` runs VChart test page locally.
64+
2. `rush react` runs React VChart test page locally.
65+
3. `rush eslint` checks the code style.
66+
4. `rush test` runs the complete test suite.
67+
5. `rush run -p <project_name> -s <script>` run the specified script for the specified project, eg. `rush run -p @visactor/vchart -s start`
68+
6. `rush prettier --dir <project_relative_path> --ext <file_type>` prettier the specified script for the specified project, eg. `rush prettier --dir packages/vchart --ext ts`
69+
70+
If you want to update documents, you can run `rush docs` to preview VChart document contents locally.

‎CONTRIBUTING.zh-CN.md

+73
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
# 贡献指南
2+
3+
首先非常感谢你能抽出时间为我们的开源项目做贡献。希望这份指南能够清晰地阐明贡献过程并回答你可能有的一些问题，所以请你在提 issue 或者 pull request 之前花几分钟时间阅读。
4+
5+
## 行为准则
6+
7+
我们有一份[行为准则](CODE_OF_CONDUCT.md)，希望所有的贡献者都能遵守，请花时间阅读一遍全文以确保你能明白哪些是可以做的，哪些是不可以做的。
8+
9+
## 透明的开发
10+
11+
我们所有的工作都会放在 [GitHub](https://github.com/VisActor/) 上。不管是核心团队的成员还是外部贡献者的 pull request 都需要经过同样流程的 review。
12+
13+
## 版本管理
14+
15+
VChart 遵循[语义化版本控制](https://semver.org/lang/zh-CN/)。我们发布 patch 补丁版本以修复重要的错误，发布 minor 次要版本以提供新功能或非必要的更改，发布 major 主要版本以适应任何重大更改。当我们进行重大更改时，在次要版本中还会引入弃用警告，以便用户了解即将到来的更改并提前迁移代码。
16+
17+
每个重要的更改我们都会记录在对应项目 CHANGELOG 更新日志中。
18+
19+
## 分支管理
20+
21+
**请将所有的更改提交到 `main` 主分支**。我们不使用单独的分支进行开发或即将发布的版本管理。我们尽力保持主分支良好状态，确保所有测试都能通过。
22+
23+
这里需要注意，所有进入主分支的代码必须与最新的稳定版本兼容，它可能包含其他功能，但不能有任何破坏性更改。我们应该能够随时从主分支的末端发布一个新的次要版本。
24+
25+
## Bugs 管理
26+
27+
我们使用 [GitHub Issues](https://github.com/VisActor/VChart/issues) 来追踪所有的缺陷。无论内外部的缺陷，我们都会在 issues 上进行管理，尽量让一切公开、清晰明了。在你报告一个 bug 之前，请先确保已经搜索
28+
过已有的 issues。
29+
30+
如果你想要你发现的 bug 被快速解决，最好的办法就是根据我们提供的 issue 模板进行提问，只需要进入 [New issue](https://github.com/VisActor/VChart/issues/new/choose) 页面，然后选择其中任意一个开始即可，最好能使用这个[模板](https://github.com/VisActor/VChart/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+) 来提供复现的示例代码。
31+
32+
## 提交变更建议
33+
34+
如果你有改进我们的配置项、接口或者新增功能的想法，我们同样推荐你通过 issue 进行提问，或者进入我们的 [New issue](https://github.com/VisActor/VChart/issues/new/choose) 页面，选择相应的 issue 模板进行提交，
35+
36+
如果你准备帮助我们修复一个 bug，那么你可以立即提交一个 pull request 请求，但我们仍然建议你先创建一个 issue 并在 issue 中详细说明将要修复的内容，这样可以帮助我们更好得追踪问题。
37+
38+
## 你的第一个 Pull Request
39+
40+
如果你还不清楚怎么在 GitHub 上提 Pull Request ，可以阅读下面这篇文章来学习：[如何优雅地在 GitHub 上贡献代码](https://segmentfault.com/a/1190000000736629)
41+
42+
为了能帮助你开始你的第一次尝试，我们用[good first issues](https://github.com/VisActor/VChart/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)标记了一些比较容易修复的 bug 和小功能。这些 issue 可以很好地作为你的首次尝试。
43+
44+
如果你打算开始处理一个 issue，请先检查一下 issue 下面的留言以确保没有别人正在处理这个 issue。如果当前没有人在处理的话你可以留言告知其他人你将会处理这个 issue，以免别人重复劳动。
45+
46+
如果之前有人留言说会处理这个 issue 但是一两个星期都没有动静，那么你也可以接手处理这个 issue，当然还是需要留言告知其他人。
47+
48+
### 如何发送 Pull Request
49+
50+
VisActor 团队会关注所有的 pull request，我们会 review 以及合并你的代码，也有可能要求你做一些修改或者告诉你我们为什么不能接受这样的修改。我们将尽最大努力在整个过程中提供及时的更新和反馈。
51+
52+
在**你发送 Pull Request 之前**，请确认你是按照下面的步骤来做的：
53+
54+
1. 基于 `main` 分支做修改
55+
2. （如果你已经安装，请跳过此步骤）全局安装 [@microsoft/rush](https://rushjs.io/pages/intro/get_started/)：`npm i --global @microsoft/rush`
56+
3. 根目录下运行 `rush update`
57+
4. 如果你修复了一个 bug 或者新增了一个功能，请确保写了相应的测试，这很重要。
58+
5. 确认所有的测试都是通过的 `rush test`。
59+
6. 如果你的修改涉及源码，确保在每次提交的时候运行 `rush change`，并且将 rush changelog 也提交上，rush changelog 保存在 `common/changes` 文件夹下。
60+
7. 运行 `rush compile` 进行 ts 类型检测。小贴士：我们在 GitHub CI 流程中也会该项检查。
61+
62+
## 开发流程
63+
64+
在你 clone 了 VChart 的代码并且使用 `rush update` 安装完依赖后，你还可以运行下面几个常用的命令：
65+
66+
1. `rush start` 在本地运行 VChart 代码的测试页面
67+
2. `rush react` 在本地运行 React-VChart 代码的测试页面
68+
3. `rush eslint` 运行所有项目的 eslint 脚本
69+
4. `rush test` 运行所有项目的 test 脚本
70+
5. `rush run -p <project_name> -s <script>` 运行指定项目的指定脚本，eg. `rush run -p @visactor/vchart -s start`
71+
6. `rush prettier --dir <project_relative_path> --ext <file_type>` 格式化指定项目的源代码，eg. `rush prettier --dir packages/vchart --ext ts`
72+
73+
如果你需要更新文档内容，你可以执行 `rush docs` 在本地运行 VChart 的文档内容预览。

‎LICENSE

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
MIT License
22

3-
Copyright (c) 2024 VisActor
3+
Copyright (c) 2023 Bytedance, Inc. and its affiliates.
44

55
Permission is hereby granted, free of charge, to any person obtaining a copy
66
of this software and associated documentation files (the "Software"), to deal

0 commit comments

Comments
 (0)