This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## @nhost/dashboard@0.19.0
### Minor Changes
- 9c61c69a7: chore(dashboard):add postgres 14.6-20230705-1 to the
version selector
### Patch Changes
- 47bda15ff: feat(settings): add warning to pull config
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## @nhost/dashboard@0.18.0
### Minor Changes
- ee0b9b8ed: chore(dashboard):add hasura v2.28.2 and v2.29.0 to the
version selector
## @nhost/docs@0.4.0
### Minor Changes
- c6fa8da6d: fix(docs): remove outdated reference/cli
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## @nhost/dashboard@0.17.19
### Patch Changes
- f866120a6: fix(users): use the password length from the config
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## @nhost/hasura-storage-js@2.2.0
### Minor Changes
- 2cdb13b3e: fix(upload): allow specifying `id` and `name` only when not
using `form-data`
## @nhost/apollo@5.2.13
### Patch Changes
- @nhost/nhost-js@2.2.11
## @nhost/react-apollo@5.0.30
### Patch Changes
- @nhost/apollo@5.2.13
- @nhost/react@2.0.26
## @nhost/react-urql@2.0.27
### Patch Changes
- @nhost/react@2.0.26
## @nhost/nextjs@1.13.32
### Patch Changes
- @nhost/react@2.0.26
## @nhost/nhost-js@2.2.11
### Patch Changes
- Updated dependencies [2cdb13b3e]
- @nhost/hasura-storage-js@2.2.0
## @nhost/react@2.0.26
### Patch Changes
- @nhost/nhost-js@2.2.11
## @nhost/vue@1.13.31
### Patch Changes
- @nhost/nhost-js@2.2.11
## @nhost/dashboard@0.17.18
### Patch Changes
- @nhost/react-apollo@5.0.30
- @nhost/nextjs@1.13.32
## @nhost-examples/node-storage@0.0.3
### Patch Changes
- 2cdb13b3e: fix(upload): allow specifying `id` and `name` only when not
using `form-data`
- @nhost/nhost-js@2.2.11
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Fixes#2071
This PR changes the API of the `hasura-storage-js` SDK slightly.
Before:
```ts
const formData = new FormData();
// first file
formData.append('file[]', '<file>');
// second file
formData.append('file[]', '<file>');
const { fileMetadata, error } = await nhost.storage.upload({
formData,
id: '<custom-uuid>', // ID doesn't make sense anymore when uploading multiple files
name: '<custom-name>', // Name doesn't make sense anymore when uploading multiple files
});
```
Now:
```ts
const formData = new FormData();
// first file
formData.append('file[]', '<file>', '<custom-name>');
formData.append('metadata[]', JSON.stringify({ id: '<custom-uuid>' }))
// second file
formData.append('file[]', '<file>', '<custom-name>');
formData.append('metadata[]', JSON.stringify({ id: '<custom-uuid>' }))
const { fileMetadata, error } = await nhost.storage.upload({ formData });
// Access the metadata of upload files via fileMetadata.processedFiles
```
The `id` and `name` attributes can only be specified if you want to
upload a single file:
```ts
const file = event.target.files[0];
const { fileMetadata, error } = await nhost.storage.upload({
file,
id: '<custom-id>',
name: '<custom-name>',
});
// Access the metadata of the upload file via fileMetadata
```
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## @nhost/google-translation@0.0.6
### Patch Changes
- a5305e6b5: docs: update old URLs to the new format
## @nhost/dashboard@0.17.17
### Patch Changes
- ea7b102c0: fix(pat): highlight expired tokens
## @nhost/docs@0.3.4
### Patch Changes
- a5305e6b5: docs: update old URLs to the new format
## @nhost-examples/seed-data-storage@0.0.4
### Patch Changes
- a5305e6b5: docs: update old URLs to the new format
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## @nhost/dashboard@0.17.11
### Patch Changes
- bd4d0c270: chore(dashboard):add postgres 14.6-20230613-1 to the
version selector
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
- We use [pnpm](https://pnpm.io/) as a package manager to speed up development and builds, and as a basis for our monorepo. You need to make sure it's installed on your machine. There are [several ways to install it](https://pnpm.io/installation), but the easiest way is with `npm`:
_⚠️ Node.js v16 is also supported for the time being but support will be dropped in the near future_.
### [pnpm](https://pnpm.io/) package manager
The easiest way to install `pnpm` if it's not installed on your machine yet is to use `npm`:
```sh
$ npm install -g pnpm
```
- Our tests and examples use the Nhost CLI, to run the backend services locally. You can follow the installation instructions in [our documentation](https://docs.nhost.io/get-started/cli-workflow/install-cli).
### [Nhost CLI](https://docs.nhost.io/cli)
- The CLI is primarily used for running the E2E tests
- Please refer to the [installation guide](https://docs.nhost.io/get-started/cli-workflow/install-cli) if you have not installed it yet
## File Structure
The repository is organized as a monorepo, with the following structure (only relevant folders are shown):
```
assets/ # Assets used in the README
config/ # Configuration files for the monorepo
dashboard/ # Dashboard
docs/ # Documentation website
examples/ # Example projects
packages/ # Core packages
integrations/ # These are packages that rely on the core packages
```
## Get started
@@ -31,25 +52,25 @@ $ pnpm install
### Development
Although package references are correctly updated on the fly for TypeScript, example projects won't
see the changes because they are depending on the build output. To fix this, you can run packages
in development mode.
Although package references are correctly updated on the fly for TypeScript, example projects and the dashboard won't see the changes because they are depending on the build output. To fix this, you can run packages in development mode.
Running packages in development mode is as simple as:
Running packages in development mode from the root folder is as simple as:
```sh
$ pnpm dev
```
Our packages are linked together using [PNPM's workspace](https://pnpm.io/workspaces) feature. Vite automatically detects changes in the dependencies and rebuilds everything, so that the changes are immediately reflected in the other packages.
Our packages are linked together using [PNPM's workspace](https://pnpm.io/workspaces) feature. Next.js and Vite automatically detect changes in the dependencies and rebuild everything, so the changes will be reflected in the examples and the dashboard.
### Use examples
**Note:** It's possible that Next.js or Vite throw an error when you run `pnpm dev`. Restarting the process should fix it.
### Use Examples
Examples are a great way to test your changes in practice. Make sure you've `pnpm dev` running in your terminal and then run an example.
Let's follow the instructions to run [react-apollo example](https://github.com/nhost/nhost/blob/main/examples/react-apollo/README.md).
## Run the documentation website locally
## Edit Documentation
The easier way to contribute to our documentation is to go to the `docs` folder and follow the [instructions to start local development](https://github.com/nhost/nhost/blob/main/docs/README.md):
@@ -60,9 +81,9 @@ $ pnpm install
$ pnpm start
```
## Run test suites
## Run Test Suites
### Unit tests
### Unit Tests
You can run the unit tests with the following command from the repository root:
@@ -70,7 +91,7 @@ You can run the unit tests with the following command from the repository root:
$ pnpm test
```
### End-to-end tests
### E2E Tests
Each package that defines end-to-end tests embeds their own Nhost configuration, that will be automatically when running the tests. As a result, you must make sure you are not running the Nhost CLI before running the tests.
@@ -83,24 +104,60 @@ $ pnpm e2e
## Changesets
If you've made changes to the packages, you must describe those changes so that they can be reflected in the next release.
We use [changesets](https://github.com/changesets/changesets) to support our versioning and release workflows. When you submit a pull request, a bot checks if some changesets are present, and if not, it directs you to add them.
We use [changesets](https://github.com/changesets/changesets) to support our versioning and release workflows. When you submit a pull request, a bot checks if changesets are present, and if not, it asks you to add them.
The most comprehensive way to add a changeset is to run the following command in the repository root:
To create a changeset, run the following command from the repository root:
```sh
$ pnpm changeset
```
This will create a file in the `.changeset` directory. You can edit it to give more details about the change you just made.
This command will guide you through the process of creating a changeset. It will create a file in the `.changeset` directory.
You can take a look at the changeset documentation: [How to add a changeset](https://github.com/changesets/changesets/blob/main/docs/adding-a-changeset.md).
## Committing changes
### Selecting the Version
You'll notice that `git commit` takes a few seconds to run. We set a commit hook that scans the changes in the code, automatically generates documentation from the inline [TSDoc](https://tsdoc.org/) annotations, and adds these generated documentation files to the commit. They automatically update the [reference documentation](https://docs.nhost.io/reference).
When you create a changeset, you will be asked to select the version of the package that you are bumping. The versioning scheme is as follows:
- **major**
- For breaking changes (e.g: changing the function signature, etc.)
- Should be avoided as much as possible as it will require users to update their code. Instead, consider supporting both the old and the new API simultaneously for a while.
- For example: `v1.5.8` -> `v2.0.0`
- **minor**
- For new features (e.g: adding a new page to the dashboard, etc.)
- For example: `v1.5.8` -> `v1.6.0`
- **patch**
- For bug fixes (e.g: fixing a typo, etc.)
- For example: `v1.5.8` -> `v1.5.9`
<!-- ## Good practices
- lint
- prettier
- documentation -->
### Writing Good Changesets
A concise summary that describes the changes should be added to each PR. This summary will be used as the changeset description.
The following structure is used for describing changes:
- **The type of the change**:
- fix
- feat
- chore
- docs
- **The scope of the change** (_broader scopes (e.g: dashboard, hasura-storage-js, etc.) are not recommended as GitHub Releases already contain which project is being bumped_):
- projects
- deployments
- deps
- etc.
- **A short summary of the changes that were made**
**Examples:**
-`fix(deployments): use correct timestamp for deployment details`
-`chore(deps): bump @types/react to v18.2.8`
-`feat(secrets): enable secrets`
- etc.
You can always take a look at examples of changesets in the [GitHub Releases section](https://github.com/nhost/nhost/releases).
| `react/react-in-jsx-scope` | Disabled because we don't need to import `React` anymore. |
| `react/jsx-props-no-spreading` | Disabled because we heavily rely on props spreading in our `@/ui/v2` components. |
| `react/jsx-props-no-spreading` | Disabled because we heavily rely on props spreading in our `@/components/ui/v2` components. |
| `react/require-default-props` | Disabled because we use TypeScript instead of PropTypes. |
| `react-hooks/exhaustive-deps` | Because we already had several rule violations when proper ESLint rules were introduced, we changed this rule to a warning. |
| `import/extensions` | JS / TS files should be imported without file extensions. |
@@ -101,7 +123,6 @@ pnpm storybook
| `import/order` | Until we have a better auto-formatter, we disable this rule. |
| `import/no-extraneous-dependencies` | `devDependencies` should be excluded from the list of disallowed imports. |
| `curly` | By default it only enforces curly braces for multi-line blocks, but it should be enforced for single-line blocks as well. |
| `no-restricted-exports` | `export { default } from './module'` is used heavily in `@/ui/v2` which is a restricted export by default. |
| `@typescript-eslint/no-use-before-define` | Order of type references should be ignored. |
| `no-undef` | [Official TypeScript ESLint packages](https://github.com/typescript-eslint/typescript-eslint/issues/4671#issuecomment-1065948494) are turning off this rule. |
| `@typescript-eslint/no-shadow` | TypeScript specific implementation of `no-shadow`. |
@@ -111,15 +132,19 @@ pnpm storybook
| `@typescript-eslint/naming-convention` | Enforces a consistent naming convention. |
| `no-restricted-imports` | Enforces absolute imports and consistent import paths for components from `src/components/ui` folder. |
### End-to-End Tests
### Unit Tests
End-to-end tests are written using [Playwright](https://playwright.dev/). To run the tests, run the following command:
Unit tests are written using [Vitest](https://vitest.dev/). To run the tests, run the following command:
```bash
pnpm e2e
pnpm test
```
Most of the tests require access to the Nhost test user. To run these tests, you need to set the following environment variables in `.env.test`:
### End-to-End Tests
Most of the end-to-end tests require access to an Nhost test user and a live project. You can register a user and create a test project on the [Nhost Dashboard](https://app.nhost.io/).
Next, you need to create a project. Create a `.env.test` file with the following variables:
@@ -28,13 +27,18 @@ export function InviteAnnounce() {
useSubmitState();
// @FIX: We probably don't want to poll every ten seconds for possible invites. (We can change later depending on how it works in production.) Maybe just on the workspace page?
const{data,loading,error,refetch,startPolling}=
useGetWorkspaceMemberInvitesToManageQuery({
variables:{
userId: user?.id,
},
skip:!isPlatform||!user,
});
const{
data,
loading,
error,
refetch: refetchInvitations,
startPolling,
}=useGetWorkspaceMemberInvitesToManageQuery({
variables:{
userId: user?.id,
},
skip:!isPlatform||!user,
});
useEffect(()=>{
startPolling(15000);
@@ -79,9 +83,14 @@ export function InviteAnnounce() {
});
}
awaitupdateOwnCache(client);
awaitclient.refetchQueries({
include:[
GetAllWorkspacesAndProjectsDocument,
GetWorkspaceMemberInvitesToManageDocument,
],
});
awaitrouter.push(`/${invite.workspace.slug}`);
awaitrefetch();
awaitrefetchInvitations();
triggerToast('Workspace invite accepted');
returnsetSubmitState({
error: null,
@@ -189,5 +198,3 @@ export function InviteAnnounce() {
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.