@powerhousedao/academy 2.5.0-dev.1 → 2.5.0-dev.11
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,73 @@
|
|
|
1
|
+
## 2.5.0-dev.11 (2025-06-07)
|
|
2
|
+
|
|
3
|
+
### 🚀 Features
|
|
4
|
+
|
|
5
|
+
- **connect:** updated diff-analyzer processor ([ce5d1219f](https://github.com/powerhouse-inc/powerhouse/commit/ce5d1219f))
|
|
6
|
+
|
|
7
|
+
### ❤️ Thank You
|
|
8
|
+
|
|
9
|
+
- acaldas
|
|
10
|
+
|
|
11
|
+
## 2.5.0-dev.10 (2025-06-06)
|
|
12
|
+
|
|
13
|
+
### 🚀 Features
|
|
14
|
+
|
|
15
|
+
- run analytics db on web worker ([ecf79575f](https://github.com/powerhouse-inc/powerhouse/commit/ecf79575f))
|
|
16
|
+
|
|
17
|
+
### ❤️ Thank You
|
|
18
|
+
|
|
19
|
+
- acaldas
|
|
20
|
+
|
|
21
|
+
## 2.5.0-dev.9 (2025-06-05)
|
|
22
|
+
|
|
23
|
+
This was a version bump only for @powerhousedao/academy to align it with other projects, there were no code changes.
|
|
24
|
+
|
|
25
|
+
## 2.5.0-dev.8 (2025-06-05)
|
|
26
|
+
|
|
27
|
+
This was a version bump only for @powerhousedao/academy to align it with other projects, there were no code changes.
|
|
28
|
+
|
|
29
|
+
## 2.5.0-dev.7 (2025-06-05)
|
|
30
|
+
|
|
31
|
+
This was a version bump only for @powerhousedao/academy to align it with other projects, there were no code changes.
|
|
32
|
+
|
|
33
|
+
## 2.5.0-dev.6 (2025-06-05)
|
|
34
|
+
|
|
35
|
+
### 🩹 Fixes
|
|
36
|
+
|
|
37
|
+
- set node 22 in release branch workflow ([b33681938](https://github.com/powerhouse-inc/powerhouse/commit/b33681938))
|
|
38
|
+
|
|
39
|
+
### ❤️ Thank You
|
|
40
|
+
|
|
41
|
+
- Frank
|
|
42
|
+
|
|
43
|
+
## 2.5.0-dev.5 (2025-06-05)
|
|
44
|
+
|
|
45
|
+
This was a version bump only for @powerhousedao/academy to align it with other projects, there were no code changes.
|
|
46
|
+
|
|
47
|
+
## 2.5.0-dev.4 (2025-06-05)
|
|
48
|
+
|
|
49
|
+
### 🩹 Fixes
|
|
50
|
+
|
|
51
|
+
- **builder-tools:** move esbuild dev dep to deps ([baa22be6f](https://github.com/powerhouse-inc/powerhouse/commit/baa22be6f))
|
|
52
|
+
|
|
53
|
+
### ❤️ Thank You
|
|
54
|
+
|
|
55
|
+
- ryanwolhuter @ryanwolhuter
|
|
56
|
+
|
|
57
|
+
## 2.5.0-dev.3 (2025-06-05)
|
|
58
|
+
|
|
59
|
+
### 🚀 Features
|
|
60
|
+
|
|
61
|
+
- **builder-tools:** add node polyfills esbuild plugin for connect build ([43dd16b4d](https://github.com/powerhouse-inc/powerhouse/commit/43dd16b4d))
|
|
62
|
+
|
|
63
|
+
### ❤️ Thank You
|
|
64
|
+
|
|
65
|
+
- ryanwolhuter
|
|
66
|
+
|
|
67
|
+
## 2.5.0-dev.2 (2025-06-05)
|
|
68
|
+
|
|
69
|
+
This was a version bump only for @powerhousedao/academy to align it with other projects, there were no code changes.
|
|
70
|
+
|
|
1
71
|
## 2.5.0-dev.1 (2025-06-05)
|
|
2
72
|
|
|
3
73
|
This was a version bump only for @powerhousedao/academy to align it with other projects, there were no code changes.
|
|
@@ -202,15 +202,79 @@ If you're publishing a package under a scope (like @your-org/my-package), you mi
|
|
|
202
202
|
}
|
|
203
203
|
```
|
|
204
204
|
|
|
205
|
-
|
|
205
|
+
### 2.1 Versioning, Tagging, and Publishing Your Package
|
|
206
|
+
|
|
207
|
+
Before publishing, it's crucial to version your package correctly and tag the release in your Git repository. This helps track changes and allows users to depend on specific versions.
|
|
208
|
+
|
|
209
|
+
**1. Versioning with PNPM**
|
|
210
|
+
|
|
211
|
+
Use the `pnpm version` command to update your package version according to semantic versioning rules (`patch` for bugfixes, `minor` for new features, `major` for breaking changes). This command will:
|
|
212
|
+
- Update the `version` in your `package.json`.
|
|
213
|
+
- Create a Git commit for the version change.
|
|
214
|
+
- Create a Git tag for the new version (e.g., `v1.0.1`).
|
|
215
|
+
|
|
216
|
+
```bash
|
|
217
|
+
# For a patch release (e.g., from 1.0.0 to 1.0.1)
|
|
218
|
+
pnpm version patch
|
|
219
|
+
|
|
220
|
+
# For a minor release (e.g., from 1.0.1 to 1.1.0)
|
|
221
|
+
pnpm version minor
|
|
222
|
+
|
|
223
|
+
# For a major release (e.g., from 1.1.0 to 2.0.0)
|
|
224
|
+
pnpm version major
|
|
225
|
+
```
|
|
226
|
+
Take note of the new version tag created (e.g., `v1.0.1`), as you'll need it in the next step.
|
|
227
|
+
|
|
228
|
+
**2. Pushing Changes to Git**
|
|
229
|
+
|
|
230
|
+
Next, push your commits and the new version tag to your remote Git repository:
|
|
231
|
+
|
|
232
|
+
```bash
|
|
233
|
+
# Push your current branch (e.g., main or master)
|
|
234
|
+
# Replace 'main' with your default branch name if different
|
|
235
|
+
git push origin main
|
|
236
|
+
|
|
237
|
+
# Push the specific tag created by pnpm version
|
|
238
|
+
# Replace vX.Y.Z with the actual tag name (e.g., v1.0.1)
|
|
239
|
+
git push origin vX.Y.Z
|
|
240
|
+
```
|
|
241
|
+
The specific tag name (e.g., `v1.0.1`) is usually output by the `pnpm version` command. Pushing the specific tag is recommended to avoid unintentionally pushing other local tags.
|
|
242
|
+
|
|
243
|
+
Alternatively, to push all new local tags (use with caution):
|
|
244
|
+
```bash
|
|
245
|
+
# git push --tags
|
|
246
|
+
```
|
|
247
|
+
|
|
248
|
+
**3. Understanding Git Tags vs. NPM Distributor Tags**
|
|
249
|
+
|
|
250
|
+
It's important to distinguish between Git tags and NPM distributor tags (dist-tags):
|
|
251
|
+
|
|
252
|
+
- **Git Tags**: These are markers in your Git repository's history. They are primarily for developers to pinpoint specific release versions in the codebase (e.g., `v1.0.0`, `v1.0.1`). The `pnpm version` command creates these.
|
|
253
|
+
- **NPM Distributor Tags (dist-tags)**: These are labels used by the NPM registry to point to specific published versions of your package. Common NPM tags include:
|
|
254
|
+
- `latest`: This is the default tag. When someone runs `pnpm install my-package`, NPM installs the version tagged as `latest`.
|
|
255
|
+
- `beta`, `next`, `alpha`: Often used for pre-release versions.
|
|
256
|
+
When you publish a package without specifying an NPM tag, it usually gets the `latest` tag by default.
|
|
257
|
+
|
|
258
|
+
**4. Publishing to NPM**
|
|
259
|
+
|
|
260
|
+
Now you are ready to publish your package to the NPM registry. Ensure you are logged into NPM (the `npm login` command shown in previous steps should be used, or `pnpm login` which is an alias).
|
|
261
|
+
|
|
262
|
+
```bash
|
|
263
|
+
pnpm publish
|
|
264
|
+
```
|
|
265
|
+
This command will publish the version of your package that is currently specified in your `package.json`. By default, this will also set the `latest` NPM dist-tag for this version.
|
|
266
|
+
|
|
267
|
+
If your package is scoped (e.g., `@your-org/my-package`) and intended to be public, ensure your `package.json` includes the `publishConfig` shown earlier. If this is not set in `package.json` (and your package is scoped), you might need to use:
|
|
206
268
|
```bash
|
|
207
|
-
|
|
269
|
+
pnpm publish --access public
|
|
208
270
|
```
|
|
209
271
|
|
|
210
|
-
|
|
272
|
+
You can also publish a version to a specific NPM dist-tag. For example, to publish a beta version:
|
|
211
273
|
```bash
|
|
212
|
-
|
|
274
|
+
# Ensure your package.json version reflects the beta (e.g., 1.1.0-beta.0)
|
|
275
|
+
pnpm publish --tag beta
|
|
213
276
|
```
|
|
277
|
+
This is useful for testing releases before making them `latest`.
|
|
214
278
|
|
|
215
279
|
Now let's verify that the package(s) get published in the package repository, next to pre-existing packages that you might have been publishing before.
|
|
216
280
|
|
|
@@ -43,7 +43,7 @@ import { Tabs, TabItem } from '@theme/Tabs';
|
|
|
43
43
|
- **Error Message Example:** "Invalid PHID format. Please check the document ID, branch, or scope."
|
|
44
44
|
</details>
|
|
45
45
|
|
|
46
|
-
The following is
|
|
46
|
+
The following is the UI component for the PHID field and scalar in a storybook.
|
|
47
47
|
We use Storybook as our component development environment.
|
|
48
48
|
It allows us to build and test UI components in isolation, making it easier to develop, test, and document reusable components.
|
|
49
49
|
In our stories you'll find first find a basic UI implementation example of the component, followed by the component's properties, events, and validation options.
|