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
We primarily develop in `yarn`, but use `npm` in our benchmarks. Please make sure to have something like:
8
+
We manage dependencies using `npm`. Note that for the time being, our development tools assume a Unix-like environment, which means Mac, Linux, or something like the Windows Subsystem for Linux.
9
9
10
-
* node: `8+`
11
-
* yarn: (anything modern)
12
-
* npm: (anything modern)
13
-
14
-
available. Also note that for the time being, our development tools assume a Unix-like environment, which means Mac, Linux, or something like the Windows Subsystem for Linux.
15
-
16
-
Our development revolves around various fixture packages we have in `test`. Get set up with:
17
-
18
-
```sh
19
-
$ yarn
20
-
21
-
# If not changing deps
22
-
$ yarn benchmark:ci
23
-
# If changing deps
24
-
$ yarn benchmark:install
25
-
```
26
-
27
-
to install the root project and a lot of fixture packages. (This is **meant** to take a while as we install a lot of dependencies to give us sizable app simulations to work with...) You will need to re-run `benchmark:install` whenever you update dependencies inside `test/` packages.
28
-
29
-
Our present fixture setup is:
30
-
31
-
```
32
-
$ tree test/packages/ -L 2
33
-
test/packages/
34
-
├── complex
35
-
│ ├── npm
36
-
│ └── yarn
37
-
└── simple
38
-
├── npm
39
-
└── yarn
40
-
```
41
-
42
-
**Note**: Only **some** of the scenarios contribute to the timed benchmark results as some scenarios don't actually use either built-in Serverless or Jetpack packaging.
43
-
44
-
For ease of development, we want to do `yarn benchmark:ci`/`yarn benchmark:install` and install the respective yarn/npm packages **once**. However, this means we keep duplicates of source code / package.json files across the `npm`/`yarn` variant directories. To keep things in sync, we designate the `yarn` directory as "the source of truth" for everything except for `SCENARIO/npm/package-lock.json` and copy files across scenarios with:
45
-
46
-
```sh
47
-
$ yarn benchmark:build
48
-
```
49
-
50
-
From there you can run various packaging configurations and perform benchmarks.
# Faster, because scenarios run in parallel, but less reliable results because
58
-
# of impact on your machine. Use this for faster development, but do a normal
59
-
# serial benchmark for pasting results.
60
-
# ... using all CPU cores
61
-
$ yarn benchmark --parallel
62
-
# ... or set the level of concurrency manually
63
-
$ yarn benchmark --concurrency=2
64
-
```
65
-
66
-
After this, we can run benchmark specific QA stuff:
10
+
Get set up with:
67
11
68
12
```sh
69
-
$ yarn benchmark:test
13
+
$ npm install
14
+
$ npm run test:install
70
15
```
71
16
72
-
(The `lint` needs the individual installs and `test` needs file list output from a full benchmark).
17
+
to install the root project and our test fixtures.
73
18
74
19
## Checks
75
20
76
-
### Fast stuff
77
-
78
21
Run these often -- unit tests and lint:
79
22
80
23
```sh
81
-
$ yarn lint
82
-
$ yarntest
24
+
$ npm run lint
25
+
$ npm runtest
83
26
84
27
# ... or all together ...
85
-
$ yarn run check
86
-
```
87
-
88
-
### Slow stuff
89
-
90
-
Run these before a PR and when changing things / kicking tires...
91
-
92
-
*Requirements*: For CLI and benchmark tests...
93
-
94
-
```sh
95
-
# Install once (or on changes to dependencies or fixtures)
96
-
$ yarn benchmark:ci # or yarn benchmark:install if changing deps
97
-
$ yarn benchmark:build
98
-
```
99
-
100
-
*CLI tests*: Use the fixtures
101
-
102
-
```sh
103
-
$ yarn test:cli
104
-
```
105
-
106
-
*Benchmark tests*: Run the benchmark to gather data and assess correctness of packages vs. real Serverless.
107
-
108
-
```sh
109
-
$ yarn benchmark
110
-
$ yarn benchmark:test
111
-
```
112
-
113
-
*Serverless Enterprise*: Unfortunately, these tests require a login account and special `SERVERLESS_ACCESS_KEY` environment variable. The Jetpack project has two active tokens for `localdev` and `ci`. You can enable these and our `dashboard` tests with something like:
@@ -123,34 +34,14 @@ Before you go ahead and submit a PR, make sure that you have done the following:
123
34
124
35
```sh
125
36
# Update the documentation TOCs (and commit changes).
126
-
$ yarn run build
37
+
$ npm run build
127
38
128
39
# Run lint and unit tests
129
-
$ yarn run check
130
-
131
-
# Make sure all fixtures are updated and valid
132
-
$ yarn benchmark:install
133
-
$ yarn benchmark:ci
134
-
$ yarn benchmark:build
40
+
$ npm run check
135
41
136
42
# After this, you can run the CLI tests which use real fixtures in E2E scenarios
137
-
# They're relatively slow (several seconds a test), but nowhere near as slow
138
-
# as the benchmark.
139
-
$ yarn test:cli
140
-
141
-
# Run a benchmark.
142
-
# Then, actually generate the benchmark.
143
-
# _Note_: Unfortunately, this takes some **time**. Grab a ☕
144
-
$ yarn benchmark
145
-
# Now, test the benchmark for correctness.
146
-
$ yarn benchmark:test
147
-
148
-
# If the timed benchmark stats and/or usage is notably different
149
-
# than what's in README.md, update relevant sections and commit your changes.
150
-
$ vim README.md
151
-
152
-
# Run all final checks.
153
-
$ yarn run check
43
+
# They're relatively slow (several seconds a test).
44
+
$ npm run test:cli
154
45
```
155
46
156
47
### Using changesets
@@ -168,7 +59,7 @@ Here are more details:
168
59
When you would like to add a changeset (which creates a file indicating the type of change), in your branch/PR issue this command:
169
60
170
61
```sh
171
-
$ yarn changeset
62
+
$ npm exec changeset
172
63
```
173
64
174
65
to produce an interactive menu. Navigate the packages with arrow keys and hit `<space>` to select 1+ packages. Hit `<return>` when done. Select semver versions for packages and add appropriate messages. From there, you'll be prompted to enter a summary of the change. Some tips for this summary:
@@ -211,4 +102,4 @@ On the merge of a version packages PR, the changesets GitHub action will publish
211
102
4. Run `npm publish` and publish to NPM if all is well.
0 commit comments