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/become-a-contributor.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Become A Contributor
2
2
3
-
Anyone can contribute to EmberData. Contributing can be as simple as opening an issue or helping to track down the cause of one. Or as involved as contributing a fix, helping with routine maintenance, or implementing a big new feature.
3
+
Anyone can contribute to WarpDrive. Contributing can be as simple as opening an issue or helping to track down the cause of one. Or as involved as contributing a fix, helping with routine maintenance, or implementing a big new feature.
4
4
5
5
In addition to holding discussions on individual [issues](https://github.com/emberjs/data/issues)
6
6
or [RFCs](https://github.com/emberjs/rfcs/labels/T-ember-data), we coordinate work when needed in the `#dev-ember-data` channel on [Ember's Discord Server](https://discord.gg/zT3asNS).
Any identifier supplied by an EmberData API will always be the stable variant. APIs which are operating based on identity and which can reasonably presume that the data exists expect stable identifiers and should error if an unknown identifier is encountered to prevent potential system-correctness errors.
36
+
Any identifier supplied by a WarpDrive API will always be the stable variant. APIs which are operating based on identity and which can reasonably presume that the data exists expect stable identifiers and should error if an unknown identifier is encountered to prevent potential system-correctness errors.
Copy file name to clipboardexpand all lines: contributing/linking-to-applications.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
-
#### Testing EmberData source directly in your Application
1
+
#### Testing WarpDrive source directly in your Application
2
2
3
-
You can use package linking to test checkouts of ember-data against your application locally. This applies to consuming ember-data directly within an ember application. It will not work in your application if you are consuming ember-data through an addon (transitive dependency problem). This approach also presumes consuming all of ember-data.
3
+
You can use package linking to test checkouts of WarpDrive against your application locally. This applies to consuming WarpDrive directly within an ember application. It will not work in your application if you are consuming WarpDrive through an addon (transitive dependency problem). This approach also presumes consuming all of WarpDrive.
4
4
5
5
1. clone this repository or another fork
6
6
2. install dependencies: `pnpm install`
@@ -14,4 +14,4 @@ If using `pnpm`
14
14
15
15
If you don't use pnpm in your application, using the appropriate `yarn link` and `npm link` commands within the respective directories for the project and your app may work.
16
16
17
-
Once you have linked EmberData to your application, you can run `ember serve` as usual in your application.
17
+
Once you have linked WarpDrive to your application, you can run `ember serve` as usual in your application.
Copy file name to clipboardexpand all lines: contributing/setting-up-the-project.md
+28-1
Original file line number
Diff line number
Diff line change
@@ -68,9 +68,36 @@ Currently the install command is also what builds all of the individual packages
68
68
## Create certificates
69
69
70
70
```sh
71
-
pnpx @warp-drive/holodeck ensure-cert
71
+
pnpm dlx @warp-drive/holodeck ensure-cert
72
72
```
73
73
74
+
## Building the project
75
+
76
+
The project's packages will build whenever `pnpm install` is run. They can be rebuilt by running `pnpm prepare`.
77
+
78
+
Both `install` and `prepare` will ensure turbo cache is ignored so that pnpm will automatically update "hardlinks" for
79
+
the build output files in the node_modules directory of the various other packages and test apps that depend upon the package.
80
+
81
+
However, this is pretty slow for development, so a fast albeit slightly manual approach is available for development
82
+
by running the below commands in order:
83
+
84
+
From the project root:
85
+
86
+
- install: `pnpm install` - installs all dependencies and sets up initial hardlinks
87
+
- start: `pnpm start` - starts the build for every public package in watch mode
88
+
89
+
Then, from an individual test app:
90
+
91
+
-`pnpm start` - starts the build for test assets in watch mode
92
+
-`pnpm test:start` - launches a test server (and by opens a browser window for debugging them)
93
+
94
+
Because the project uses hardlinks, even though the packages are rebuilding, the test apps won't be able
95
+
to see the results of the change in many scenarios unless the hardlinks are regenerated.
96
+
97
+
At anypoint, run `pnpm sync` from the root to regenerate the hardlinks. The test app server may
98
+
pick up this change automatically, but if it does not saving any file (even without changing it)
99
+
in the test app will trigger a rebuild.
100
+
74
101
## Run some commands
75
102
76
103
Generally test and lint commands can be found in the `"scripts"` section of the root `package.json` manifest. Individual packages or test packages have additional commands in the `"scripts"` section of their own `package.json` manifest as well.
Copy file name to clipboardexpand all lines: contributing/submitting-prs.md
+5-3
Original file line number
Diff line number
Diff line change
@@ -19,15 +19,17 @@ All PRs should have accompanying tests. For bug-fixes, this should include tests
19
19
the issue being fixed and test that the solution works.
20
20
21
21
- We do write tests for our deprecations and assertion messages, using the `assert.expectAssertion()` and `assert.expectDeprecation()` helpers.
22
-
- Because we run tests in both development and `production` environments, assertions, deprecations and warnings may be stripped out. To avoid tests on failing for your PR in production environments, use the `testInDebug` function instead of `qunit``test` to skip them in production when appropriate.
22
+
- Because we run tests in both development and `production` environments, assertions, deprecations and warnings may be stripped out. To avoid tests of debug behaviors failing for your PR in production environments, use the `testInDebug` function instead of `qunit``test` to skip them in production when appropriate.
23
+
- alternatively wrap specific assertions in `if (DEBUG)` or `if (PRODUCTION)`
23
24
- Update the documentation, examples, and guides when affected by your contribution
24
25
25
26
### Running Tests
26
27
27
28
- PRs will automatically run an extensive set of test scenarios for your work. In some cases a contributor
28
29
may need to approve the workflow run if this is your first contribution.
29
-
-`EmberData` is a collection of packages and comes with multiple test apps scoped to specific situations
30
-
or parts of the codebase we want to test. Tests live in the test applications in `<project>/tests`. These should look like familiar ember app/addon tests, and to run them from within a specific test app use `pnpm test` or `pnpm test --serve`. For additional test commands see the list
30
+
-`WarpDrive` is a collection of packages and comes with multiple test apps scoped to specific situations
31
+
or parts of the codebase we want to test. These test applications can be found in `<project>/tests`.
32
+
These should look like familiar ember app/addon tests, and to run them from within a specific test app use `pnpm test` or `pnpm test --serve`. For additional test commands see the list
31
33
of commands in the respective `package.json` files.
![renovate[bot]](https://avatars.githubusercontent.com/in/2740?v=4&size=40){kind=avatar}
0 commit comments