You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+10-10Lines changed: 10 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -116,7 +116,7 @@ pnpm run test
116
116
pnpm run test:match "$STRING_MATCH"
117
117
# run tests on another package
118
118
# (example - `pnpm --filter @astrojs/rss run test` runs `packages/astro-rss/test/rss.test.js`)
119
-
pnpm --filter $STRING_MATCH run test
119
+
pnpm --filter "$STRING_MATCH" run test
120
120
```
121
121
122
122
Most tests use [`mocha`](https://mochajs.org) as the test runner. We're slowly migrating to use [`node:test`](https://nodejs.org/api/test.html) instead through the custom [`astro-scripts test`](./scripts/cmd/test.js) command. For packages that use `node:test`, you can run these commands in their directories:
There might be occasions where some tests fail in certain CI runs due to some timeout issue. If this happens, it will be very difficult to understand which file cause the timeout. That's caused by come quirks of the Node.js test runner combined with our architecture.
168
+
There might be occasions where some tests fail in certain CI runs due to some timeout issue. If this happens, it will be very difficult to understand which file cause the timeout. That's caused by some quirks of the Node.js test runner combined with our architecture.
169
169
170
170
To understand which file causes the issue, you can modify the `test` script inside the `package.json` by adding the `--parallel` option:
171
171
@@ -176,7 +176,7 @@ To understand which file causes the issue, you can modify the `test` script insi
176
176
}
177
177
```
178
178
179
-
Save the change and **push it** to your PR. This change will make the test CI slower, but it will allow to see which files causes the timeout. Once you fixed the issue **revert the change and push it**.
179
+
Save the change and **push it** to your PR. This change will make the test CI slower, but it will allow to see which files cause the timeout. Once you fixed the issue **revert the change and push it**.
180
180
181
181
#### E2E tests
182
182
@@ -194,7 +194,7 @@ pnpm run test:e2e:match "$STRING_MATCH"
194
194
195
195
Any tests for `astro build` output should use the main `mocha` tests rather than E2E - these tests will run faster than having Playwright start the `astro preview` server.
196
196
197
-
If a test needs to validate what happens on the page after it's loading in the browser, that's a perfect use for E2E dev server tests, i.e. to verify that hot-module reloading works in `astro dev` or that components were client hydrated and are interactive.
197
+
If a test needs to validate what happens on the page after it's loaded in the browser, that's a perfect use for E2E dev server tests, i.e. to verify that hot-module reloading works in `astro dev` or that components were client hydrated and are interactive.
198
198
199
199
#### Creating tests
200
200
@@ -203,8 +203,8 @@ When creating new tests, it's best to reference other existing test files and re
203
203
- When re-using a fixture multiple times with different configurations, you should also configure unique `outDir`, `build.client`, and `build.server` values so the build output runtime isn't cached and shared by ESM between test runs.
204
204
205
205
> [!IMPORTANT]
206
-
> If tests start to fail for no apparent reason, the first thing to look at the `outDir` configuration. As build cache artifacts between runs, different tests might end up sharing some of the emitted modules.
207
-
> To avoid this possible overlap, **make sure to add a custom `outDir` to your test case**
206
+
> If tests start to fail for no apparent reason, the first thing to look at the `outDir` configuration. As build caches artifacts between runs, different tests might end up sharing some of the emitted modules.
207
+
> To avoid this possible overlap, **make sure to add a custom `outDir` to your test case**.
208
208
>
209
209
> ```js
210
210
>awaitloadFixture({
@@ -259,7 +259,7 @@ To run only a specific benchmark on CI, add its name after the command in your c
259
259
260
260
## For maintainers
261
261
262
-
This paragraph provides some guidance to the maintainers of the monorepo. The guidelines explained here aren't necessarily followed by other repositories of the same GitHub organisation.
262
+
This paragraph provides some guidance to the maintainers of the monorepo. The guidelines explained here aren't necessarily followed by other repositories of the GitHub organisation.
263
263
264
264
### Issue triaging workflow
265
265
@@ -301,7 +301,7 @@ The Astro project has five levels of priority to issues, where `p5` is the highe
301
301
-`p4`: the bug impacts _many_ Astro projects, it doesn't have a workaround but Astro is still stable/usable.
302
302
-`p3`: any bug that doesn't fall in the `p4` or `p5` category. If the documentation doesn't cover
303
303
the case reported by the user, it's useful to initiate a discussion via the `"needs discussion"` label. Seek opinions from OP and other maintainers.
304
-
-`p2`: all the bugs that have workarounds.
304
+
-`p2`: all bugs that have workarounds.
305
305
-`p1`: very minor bug, that impacts a small amount of users. Sometimes it's an edge case and it's easy to fix. Very useful if you want to assign the fix to a first-time contributor.
306
306
307
307
> [!IMPORTANT]
@@ -312,7 +312,7 @@ Assigning labels isn't always easy and many times the distinction between the di
312
312
- When assigning a `p2`, **always** add a comment that explains the workaround. If a workaround isn't provided, ping the person that assigned the label and ask them to provide one.
313
313
- Astro has **many** features, but there are some that have a larger impact than others: development server, build command, HMR (TBD, we don't have a page that explains expectations of HMR in Astro), **evident** regressions in performance.
314
314
- In case the number of reactions of an issue grows, the number of users affected grows, or a discussion uncovers some insights that weren't clear before, it's OK to change the priority of the issue. The maintainer **should** provide an explanation when assigning a different label.
315
-
As with any other contribution, triaging is voluntary and best-efforts. We welcome and appreciate all the help you're happy to give (including reading this!) and nothing more. If you are not confident about an issue, you are welcome to leave an issue untriaged for someone who would have more context, or to bring it to their attention.
315
+
As with any other contribution, triaging is voluntary and best-effort. We welcome and appreciate all the help you're happy to give (including reading this!) and nothing more. If you are not confident about an issue, you are welcome to leave an issue untriaged for someone who would have more context, or to bring it to their attention.
316
316
317
317
### Preview releases
318
318
@@ -348,7 +348,7 @@ Understanding in which environment code runs, and at which stage in the process,
348
348
349
349
To make it easier to test code, try decoupling **business logic** from **infrastructure**:
350
350
351
-
-**Infrastucture** is code that depends on external systems and/or requires aspecial environment to run. For example: DB calls, file system, randomness etc...
351
+
-**Infrastructure** is code that depends on external systems and/or requires a special environment to run. For example: DB calls, file system, randomness etc...
352
352
-**Business logic** (or _core logic_ or _domain_) is the rest. It's pure logic that's easy to run from anywhere.
353
353
354
354
That means avoiding side-effects by making external dependencies explicit. This often means passing more things as arguments.
Copy file name to clipboardExpand all lines: STYLE_GUIDE.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -45,7 +45,7 @@ For example: "This is clean code" is a subjective point and should have limited
45
45
46
46
In contrast: "Tabs are more accessible than spaces" is an objective point and should be strongly considered in a theoretical style discussion on tabs vs. spaces. (Fred: Believe me, I write this as someone who personally prefers spaces over tabs in my own code!)
47
47
48
-
Sometimes, not everyone will agree on style changes and 100% consensus is impossible. This is a condition commonly referred to as bike-shedding. If consensus can not be reached, a simple majority vote among core contributors (L3) will suffice.
48
+
Sometimes, not everyone will agree on style changes and 100% consensus is impossible. This is a condition commonly referred to as bike-shedding. If consensus cannot be reached, a simple majority vote among core contributors (L3) will suffice.
49
49
50
50
_Note: This process is new, we are still figuring it out! This process will be moved into GOVERNANCE.md when finalized._
0 commit comments