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
+1-47Lines changed: 1 addition & 47 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,52 +29,6 @@ Here is the structure:
29
29
`/widget/playground`: This directory offers a playground environment where you can test and obtain configurations for our widget.
30
30
`/widget/iframe`: This directory contains a JavaScript class that simplifies the process of adding our iframe-based widget to dApps.
31
31
32
-
33
-
## Release workflow
34
-
35
-
A release can be a lib or an app/client release. We are publishing our libs to `npm` and deploying our apps (client) on `vercel`.
36
-
37
-
If a package is app, you need to add the package name to `scripts/deploy/config.mjs` and then after getting a `PROJECT_ID` from Vercel, you need to set it as enviroment variable as well.
38
-
39
-
There are main commands:
40
-
41
-
`yarn run publish` for publishing our NPM packages.
42
-
`yarn run deploy` to deploy apps on Vercel.
43
-
44
-
### Publish
45
-
46
-
#### Prerelase
47
-
48
-
Our publish script will do these steps:
49
-
50
-
1. Get the last release (by using git tags) and calculate changes since then.
51
-
2. Bump the version for changed packages.
52
-
3. Create changelog, git tags and github release, and publish them to NPM.
53
-
4. Make a publish commit and push the updated packages (version) and tags to origin.
54
-
55
-
Note:
56
-
Libs will be published under `next` tag on npm, which means you need to use `yarn add @rango/test-package@next` to install the published version whenever you need.
57
-
58
-
#### Production relase
59
-
60
-
Release should be triggered manually and then it will automatically published. You only need to run this command on you local machine to release the production:
61
-
62
-
`yarn run release-prod`
63
-
64
-
After release (Green pipleline), make sure you will merge `main` into `next` as well.
65
-
66
-
`yarn run post-release-prod`
67
-
68
-
### Deploy
69
-
70
-
You should manually trigger the `deploy` workflow.
71
-
72
-
By running `yarn run deploy`, it will build all the apps/clients then will try to deploy them on vercel.
73
-
74
-
If the workflow is running on `next` branch, it will be deployed as Vercel's `preview`. If not, it's production release.
75
-
76
-
All the apps published by `prerelase` workflow will be published under the Vercel's `preview` enviroment.
77
-
78
32
## Translation
79
33
80
34
First we need to extract the message from our source code using `yarn i18n:extract` and then we should run `yarn i18n:compile` to make a wrapper arround the translation file `.po` to be used inside our app.
@@ -115,7 +69,7 @@ Additionally, there is the option to manually trigger the crowdin workflow if ne
115
69
116
70
### How we handle urls in embedded?
117
71
118
-
`embedded` is importing in different enviroments (iframe, import as react component and a separate `app`). When it's being used as a react component we let the dApp to use it inside its router and they can load the widget in a separate route (not root `/`, e.g. `/swaps`). In this context we can not use absolute paths because we don't know the basename set by user, so we need to always use relative paths. Relative paths has been defined in [URL spec](https://url.spec.whatwg.org/#urls) so we can be sure it's a long term solution and will work in future or by changing our router librart (e.g. `react-router`).
72
+
`embedded` is importing in different environments (iframe, import as react component and a separate `app`). When it's being used as a react component we let the dApp to use it inside its router and they can load the widget in a separate route (not root `/`, e.g. `/swaps`). In this context we can not use absolute paths because we don't know the basename set by user, so we need to always use relative paths. Relative paths has been defined in [URL spec](https://url.spec.whatwg.org/#urls) so we can be sure it's a long term solution and will work in future or by changing our router librart (e.g. `react-router`).
You need to add your [Github Token](https://github.com/settings/tokens) and set it as `PAT` in your fork's secrets.
6
+
7
+
for NPM:
8
+
9
+
- Create an NPM account and an organization. (I created @yeager-dev for example)
10
+
- Get a token from NPM and set it as `NPM_TOKEN` in our repo.
11
+
- Enable Github Actions on your fork.
12
+
13
+
_Note 1_: If you are a Rango developer, you can ask NPM token for `@yeager-dev` org.
14
+
15
+
For Crowdin:
16
+
17
+
After creating a Crowdin project, it has an ID (you can find it in right sidebar) and for accessing to API you will [need a token](https://crowdin.com/settings#api-key) as well.
18
+
Then, you need to set `CROWDIN_PERSONAL_TOKEN` and `CROWDIN_PROJECT_ID` in your secrets.
A release can be a lib or an app/client release. We are publishing our libs to `npm` and deploying our apps (client) on `vercel`.
6
+
7
+
If a package is app, you need to add the package name to `scripts/deploy/config.mjs` and then after getting a `PROJECT_ID` from Vercel, you need to set it as enviroment variable as well.
8
+
9
+
There are main commands:
10
+
11
+
`yarn run publish` for publishing our NPM packages.
12
+
`yarn run deploy` to deploy apps on Vercel.
13
+
14
+
### Publish flow
15
+
16
+
#### Prerelase
17
+
18
+
Our publish script will do these steps:
19
+
20
+
1. Get the last release (by using git tags) and calculate changes since then.
21
+
2. Bump the version for changed packages.
22
+
3. Create changelog, git tags and github release, and publish them to NPM.
23
+
4. Make a publish commit and push the updated packages (version) and tags to origin.
24
+
25
+
Note:
26
+
Libs will be published under `next` tag on npm, which means you need to use `yarn add @rango/test-package@next` to install the published version whenever you need.
27
+
28
+
#### Production relase
29
+
30
+
Release should be triggered manually and then it will automatically published. You only need to run this command on you local machine to release the production:
31
+
32
+
`yarn run release-prod`
33
+
34
+
### Deploy flow
35
+
36
+
You should manually trigger the `deploy` workflow.
37
+
38
+
By running `yarn run deploy`, it will build all the apps/clients then will try to deploy them on vercel.
39
+
40
+
If the workflow is running on `next` branch, it will be deployed as Vercel's `preview`. If not, it's production release.
41
+
42
+
All the apps published by `prerelase` workflow will be published under the Vercel's `preview` enviroment.
43
+
44
+
## How you can release a new version?
45
+
46
+
### Next (Staging)
47
+
48
+
A publish only will be triggered when a **Pull Request** has been merged. If you try to commit directly into the `next` branch it wouldn't be triggered.
49
+
50
+
First it tries to extracting translations (if any) and push them onto Crowdin, then releasing libraries will be started.
51
+
_Note 1_: Syncing translations (first workflow) is an optional step which means if it fails we will do the publish anyway.
52
+
53
+
### Production
54
+
55
+
For releasing production, you need to run `yarn release-prod` it will checkout to `next` branch and pull the latest changes then it tries to merge the `next` into `main`.
56
+
_Note 1_: Make sure you are having permission for `push` on `main`.
57
+
58
+
In production, we don't run localization workflow (crowdin) since we assume our `/translation` folder is in sync with Crowdin. if you think there is new translation, you can run `crowdin` workflow manually and then try to release.
59
+
60
+
At the end, a PR will be created to merge `main` into `next` after publishing the libraries. You need to check the PR description and make sure you are considering/doing them.
0 commit comments