Mirror: The small sibling of the graphql package, slimmed down for client-side libraries.
chore: Set up GH templates
+286
-1
+42
.github/ISSUE_TEMPLATE/RFC.md
+42
.github/ISSUE_TEMPLATE/RFC.md
···
1
+
---
2
+
name: 'RFC'
3
+
about: Propose an enhancement / feature and start a discussion
4
+
title: 'RFC: Your Proposal'
5
+
labels: "future \U0001F52E"
6
+
---
7
+
8
+
<!--
9
+
🚨 RFCs are for proposed changes (not bugs or questions)
10
+
Specifically they are whenever you'd like to see new features
11
+
being added, or enable new use-cases.
12
+
13
+
Please open a Bug Report for issues/bugs, and use GitHub Discussions
14
+
or the Discord channel for questions instead.
15
+
-->
16
+
17
+
## Summary
18
+
19
+
<!--
20
+
Describe in a couple of words *what* you're proposing.
21
+
If relevant, include *why* this should be addressed now.
22
+
The problem should be clearly stated and the solution
23
+
should be summarised.
24
+
-->
25
+
26
+
## Proposed Solution
27
+
28
+
<!--
29
+
Explain the solution you're proposing in detail.
30
+
*How* will this change be implemented, and how does it work?
31
+
-->
32
+
33
+
## Requirements
34
+
35
+
<!--
36
+
This section is *optional*.
37
+
But if your proposed solution has multiple ways
38
+
of being implemented, you don't want to state how
39
+
it may be implemented, or you don't know yet how
40
+
it will be implemented, then:
41
+
*List* what the implementation needs to achieve to fulfil this RFC;
42
+
-->
+46
.github/ISSUE_TEMPLATE/bug_report.yaml
+46
.github/ISSUE_TEMPLATE/bug_report.yaml
···
1
+
name: "\U0001F41E Bug report"
2
+
description: Report an issue with graphql.web
3
+
labels: []
4
+
body:
5
+
- type: markdown
6
+
attributes:
7
+
value: |
8
+
Thanks for taking the time to fill out this bug report!
9
+
- type: markdown
10
+
attributes:
11
+
value: |
12
+
Thanks for taking the time to fill out this bug report!
13
+
- type: textarea
14
+
id: bug-description
15
+
attributes:
16
+
label: Describe the bug
17
+
description: Please describe your bug clearly and concisely.
18
+
placeholder: Bug description
19
+
validations:
20
+
required: true
21
+
- type: input
22
+
id: reproduction
23
+
attributes:
24
+
label: Reproduction
25
+
description: Please provide a reproduction link, e.g. to a sandbox
26
+
placeholder: Reproduction
27
+
validations:
28
+
required: true
29
+
- type: textarea
30
+
id: version
31
+
attributes:
32
+
label: Package version
33
+
description: The versions of the relevant urql packages you are using
34
+
placeholder: "graphql-web-lite@16.6.0-1"
35
+
validations:
36
+
required: true
37
+
- type: checkboxes
38
+
id: checkboxes
39
+
attributes:
40
+
label: Validations
41
+
description: Before submitting the issue, please make sure you do the following
42
+
options:
43
+
- label: I can confirm that this is a bug report, and not a feature request, RFC, question, or discussion, for which GitHub Discussions should be used
44
+
required: true
45
+
- label: Follow our [Code of Conduct](https://github.com/0no-co/graphql-web-lite/blob/main/CODE_OF_CONDUCT.md)
46
+
required: true
+8
.github/ISSUE_TEMPLATE/config.yml
+8
.github/ISSUE_TEMPLATE/config.yml
···
1
+
blank_issues_enabled: true
2
+
contact_links:
3
+
- name: Ask a question
4
+
url: https://github.com/0no-co/graphql-web-lite/discussions
5
+
about: Ask questions and discuss with other community members
6
+
- name: Join the Discord
7
+
url: https://discord.gg/Hw8FR8qKfC
8
+
about: Chat with maintainers and other community members
+22
.github/PULL_REQUEST_TEMPLATE.md
+22
.github/PULL_REQUEST_TEMPLATE.md
···
1
+
<!--
2
+
Thanks for opening a pull request! We appreciate your dedication and help!
3
+
Before submitting your pull request, please make sure to read our CONTRIBUTING guide.
4
+
5
+
The best contribution is always a PR, but please make sure to open an issue or discuss
6
+
your changes first, if you’re looking to submit a larger PR.
7
+
8
+
If this PR is already related to an issue, please reference it like so:
9
+
Resolves #123
10
+
-->
11
+
12
+
## Summary
13
+
14
+
<!-- What's the motivation of this change? What does it solve? -->
15
+
16
+
## Set of changes
17
+
18
+
<!--
19
+
Roughly list the changes you've made and which packages are affected.
20
+
Leave some notes on what may be noteworthy files you've changed.
21
+
And lastly, please let us know if you think this is a breaking change.
22
+
-->
+164
CONTRIBUTING.md
+164
CONTRIBUTING.md
···
1
+
# Development
2
+
3
+
Thanks for contributing! We want to ensure that `graphql-web-lite` evolves
4
+
and fulfills its idea of being a drop-in alias replacement to make your
5
+
client-side GraphQL smaller and faster!
6
+
7
+
## How to contribute?
8
+
9
+
We follow fairly standard but lenient rules around pull requests and issues.
10
+
Please pick a title that describes your change briefly, optionally in the imperative
11
+
mood if possible.
12
+
13
+
If you have an idea for a feature or want to fix a bug, consider opening an issue
14
+
first. We're also happy to discuss and help you open a PR and get your changes
15
+
in!
16
+
17
+
- If you have a question, try [creating a GitHub Discussions thread.](https://github.com/0no-co/graphql-web-lite/discussions/new/choose)
18
+
- If you think you've found a bug, [open a new issue.](https://github.com/0no-co/graphql-web-lite/issues/new)
19
+
- or, if you found a bug you'd like to fix, [open a PR.](https://github.com/0no-co/graphql-web-lite/compare)
20
+
- If you'd like to propose a change [open an RFC issue.](https://github.com/0no-co/graphql-web-lite/issues/new?labels=future+%F0%9F%94%AE&template=RFC.md&title=RFC%3A+Your+Proposal) You can read more about the RFC process [below](#how-do-i-propose-changes).
21
+
22
+
### What are the issue conventions?
23
+
24
+
There are **no strict conventions**, but we do have two templates in place that will fit most
25
+
issues, since questions and other discussion start on GitHub Discussions. The bug template is fairly
26
+
standard and the rule of thumb is to try to explain **what you expected** and **what you got
27
+
instead.** Following this makes it very clear whether it's a known behavior, an unexpected issue,
28
+
or an undocumented quirk.
29
+
30
+
### How do I propose changes?
31
+
32
+
We follow an **RFC proposal process**. This allows anyone to propose a new feature or a change, and
33
+
allows us to communicate our current planned features or changes, so any technical discussion,
34
+
progress, or upcoming changes are always **documented transparently.** You can [find the RFC
35
+
template](https://github.com/0no-co/graphql-web-lite/issues/new/choose) in our issue creator.
36
+
37
+
### What are the PR conventions?
38
+
39
+
This also comes with **no strict conventions**. We only ask you to follow the PR template we have
40
+
in place more strictly here than the templates for issues, since it asks you to list a summary
41
+
(maybe even with a short explanation) and a list of technical changes.
42
+
43
+
If you're **resolving** an issue please don't forget to add `Resolve #123` to the description so that
44
+
it's automatically linked, so that there's no ambiguity and which issue is being addressed (if any)
45
+
46
+
You'll find that a comment by the "Changeset" bot may pop up. If you don't know what a **changeset**
47
+
is and why it's asking you to document your changes, read on at ["How do I document a change for the
48
+
changelog"](#how-do-i-document-a-change-for-the-changelog)
49
+
50
+
We also typically **name** our PRs with a slightly descriptive title, e.g. `feat: Title`.
51
+
52
+
## How do I set up the project?
53
+
54
+
Luckily it's not hard to get started. You can install dependencie
55
+
[using `pnpm`](https://pnpm.io/installation#using-corepack).
56
+
Please don't use `npm` or `yarn` to respect the lockfile.
57
+
58
+
```sh
59
+
pnpm install
60
+
```
61
+
62
+
There are multiple commands you can run in the root folder to test your changes:
63
+
64
+
```sh
65
+
# TypeScript checks:
66
+
pnpm run check
67
+
68
+
# Linting (prettier & eslint):
69
+
pnpm run lint
70
+
71
+
# Unit Tests:
72
+
pnpm run test
73
+
74
+
# Builds:
75
+
pnpm run build
76
+
```
77
+
78
+
## How do I test my changes?
79
+
80
+
It's always good practice to run the tests when making changes. If you're unsure which packages
81
+
may be affected by your new tests or changes you may run `pnpm test` in the root of
82
+
the repository.
83
+
84
+
If your editor is not set up with type checks you may also want to run `pnpm run check` on your
85
+
changes.
86
+
87
+
Additionally you can head to any example in the `examples/` folder
88
+
and run them. There you'll also need to install their dependencies as they're isolated projects,
89
+
without a lockfile and without linking to packages in the monorepos.
90
+
All examples are started using the `package.json`'s `start` script.
91
+
92
+
## How do I lint my code?
93
+
94
+
We ensure consistency in this codebase using `eslint` and `prettier`.
95
+
They are run on a `precommit` hook, so if something's off they'll try
96
+
to automatically fix up your code, or display an error.
97
+
98
+
If you have them set up in your editor, even better!
99
+
100
+
## How do I document a change for the changelog?
101
+
102
+
This project uses [changesets](https://github.com/atlassian/changesets). This means that for
103
+
every PR there must be documentation for what has been changed and which package is affected.
104
+
105
+
You can document a change by running `changeset`, which will ask you which packages
106
+
have changed and whether the change is major/minor/patch. It will then ask you to write
107
+
a change entry as markdown.
108
+
109
+
```sh
110
+
# In the root of the urql repository call:
111
+
pnpm changeset
112
+
```
113
+
114
+
This will create a new "changeset file" in the `.changeset` folder, which you should commit and
115
+
push, so that it's added to your PR.
116
+
This will eventually end up in the package's `CHANGELOG.md` file when we do a release.
117
+
118
+
You won't need to add a changeset if you're simply making "non-visible" changes to the docs or other
119
+
files that aren't published to the npm registry.
120
+
121
+
[Read more about adding a `changeset` here.](https://github.com/atlassian/changesets/blob/master/docs/adding-a-changeset.md#i-am-in-a-multi-package-repository-a-mono-repo)
122
+
123
+
## How do I release new versions of our packages?
124
+
125
+
Hold up, that's **automated**! Since we use `changeset` to document our changes, which determines what
126
+
goes into the changelog and what kind of version bump a change should make, you can also use the
127
+
tool to check what's currently posed to change after a release batch using: `pnpm changeset status`.
128
+
129
+
We have a [GitHub Actions workflow](./.github/workflow/release.yml) which is triggered whenever new
130
+
changes are merged. It will always open a **"Version Packages" PR** which is kept up-to-date. This PR
131
+
documents all changes that are made and will show in its description what all new changelogs are
132
+
going to contain for their new entries.
133
+
134
+
Once a "Version Packages" PR is approved by a contributor and merged, the action will automatically
135
+
take care of creating the release, publishing all updated packages to the npm registry, and creating
136
+
appropriate tags on GitHub too.
137
+
138
+
This process is automated, but the changelog should be checked for errors.
139
+
140
+
As to **when** to merge the automated PR and publish? Maybe not after every change. Typically there
141
+
are two release batches: hotfixes and release batches. We expect that a hotfix for a single package
142
+
should go out as quickly as possible if it negatively affects users. For **release batches**
143
+
however, it's common to assume that if one change is made to a package that more will follow in the
144
+
same week. So waiting for **a day or two** when other changes are expected will make sense to keep the
145
+
fatigue as low as possible for downstream maintainers.
146
+
147
+
## How do I upgrade all dependencies?
148
+
149
+
It may be a good idea to keep all dependencies on this repository **up-to-date** every now and
150
+
then. Typically we do this by running `pnpm update --interactive --latest` and checking one-by-one
151
+
which dependencies will need to be bumped. In case of any security issues it may make sense to
152
+
just run `pnpm update [package]`.
153
+
154
+
While this is rare with `pnpm`, upgrading some transitive dependencies may accidentally duplicate
155
+
them if two packages depend on different compatible version ranges. This can be fixed by running:
156
+
157
+
```sh
158
+
pnpm dedupe
159
+
pnpm install
160
+
```
161
+
162
+
It's common to then **create a PR** (with a changeset documenting the packages that need to reflect
163
+
new changes if any `dependencies` have changed) with the name of
164
+
"(chore) - Upgrade direct and transitive dependencies" or something similar.
+2
-1
LICENSE
LICENSE.md
+2
-1
LICENSE
LICENSE.md