-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restore linting #1637
Closed
Closed
Restore linting #1637
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Upgrades `@web3-storage/upload-client` and `@web3-storage/access` to the latest versions. Causes downstream application to use the Blob protocol transparently, without affecting the API it presents. Supersedes #633, an older version of the same upgrade.
Otherwise it can't lint everything. This is solved with the [`projectService` option][1] in [`@typescript-eslint/parser` v8][2]. However, we're stuck firmly on v5 for now. [1]: https://github.com/typescript-eslint/typescript-eslint/pull/8031/files?short_path=f55b3fe#diff-f55b3fe275ea73e5e0cbfaf72c238d8fa863819992fe17e23668d1f0376a18b4 [2]: typescript-eslint/typescript-eslint@b9796c1 ### Before ```sh $ pnpm exec eslint packages/react/src/Uploader.tsx /Users/peeja/clients/storacha/w3ui/packages/react/src/Uploader.tsx 0:0 error Parsing error: ESLint was configured to run on `<tsconfigRootDir>/packages/react/src/Uploader.tsx` using `parserOptions.project`: /users/peeja/clients/storacha/w3ui/tsconfig.json However, that TSConfig does not include this file. Either: - Change ESLint's list of included files to not include this file - Change that TSConfig to include this file - Create a new TSConfig that includes this file and include it in your parserOptions.project See the typescript-eslint docs for more info: https://typescript-eslint.io/linting/troubleshooting#i-get-errors-telling-me-eslint-was-configured-to-run--however-that-tsconfig-does-not--none-of-those-tsconfigs-include-this-file ✖ 1 problem (1 error, 0 warnings) ``` ### After ```sh pnpm exec eslint packages/react/src/Uploader.tsx /Users/peeja/clients/storacha/w3ui/packages/react/src/Uploader.tsx 188:23 warning Do not nest ternary expressions no-nested-ternary 190:16 warning Do not nest ternary expressions no-nested-ternary 230:9 warning React Hook useMemo has missing dependencies: 'files', 'storedDAGShards', 'uploadAsCAR', 'uploadProgress', and 'wrapInDirectory'. Either include them or remove the dependency array react-hooks/exhaustive-deps 294:5 warning React Hook useCallback has a missing dependency: 'setWrapInDirectory'. Either include it or remove the dependency array react-hooks/exhaustive-deps ✖ 4 problems (0 errors, 4 warnings) ``` (Which, y'know, still not ideal, but at least it's _running_.)
Because we're using `createElement` from an old version of AriaKit, TS isn't checking the type of our `onSubmit` handler. It's not currently broken, but it's not being checked either. This change ensures it's correct, and makes it more correct by satisfying the types and the linter. Notably, an async function should not be a handler directly; instead, a handler should kick off an async function and attach an error handler as required. This satisfies lint rules against leaving promises dangling (apparently) accidentally.
🤖 I have created a release *beep* *boop* --- ## [2.3.0](storacha/w3ui@core-v2.2.0...core-v2.3.0) (2024-08-30) ### Features * Use client v16.0.0 and the Blob protocol ([#634](storacha/w3ui#634)) ([b079b01](storacha/w3ui@b079b01)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Petra Jaros <peeja@peeja.com>
The `Errored` component says `Check the browser console for details`, but then doesn't put the error in the console. Now it does. 😄
Version 16.2.0 of w3up-client allows Space Sharing via e-mail - which will be useful for the Console App.
🤖 I have created a release *beep* *boop* --- ## [2.3.1](storacha/w3ui@core-v2.3.0...core-v2.3.1) (2024-09-20) ### Bug Fixes * **core:** bump w3up client version ([#641](storacha/w3ui#641)) ([66e0a47](storacha/w3ui@66e0a47)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Force a new release of w3ui/react
🤖 I have created a release *beep* *boop* --- ## [2.4.0](storacha/w3ui@react-v2.3.0...react-v2.4.0) (2024-09-20) ### Features * Force a release of `@w3ui/react` ([#639](storacha/w3ui#639)) ([8f10864](storacha/w3ui@8f10864)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Use `pnpm dev` to build both packages in watch mode. Also, upgrades `bunchee` to get past [a bug in its watch mode](huozhi/bunchee#383). This is a big upgrade (two major versions), but everything builds fine—the upgrade doesn't appear to be as breaking as that sounds. Worth double-checking, though.
[As in `console`.](storacha/console#117)
The rest of storacha/project-tracking#125. This along with [generating the space delegations on the fly during `access/claim`](storacha/w3up#1555) will make new spaces appear on the page without logging out. --- If the client is restored from local storage, it may be out of date. This fetches the latest delegations from the server and updates the client. This makes loading the client from local storage a stale-while-revalidate operation.
🤖 I have created a release *beep* *boop* --- ## [2.5.0](storacha/w3ui@react-v2.4.0...react-v2.5.0) (2024-10-07) ### Features * Re-`claim` delegations during client setup ([#644](storacha/w3ui#644)) ([7d34281](storacha/w3ui@7d34281)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This PR adds a router interface: ```ts /** * The routing service is responsible for selecting storage nodes to allocate * blobs with. */ export interface RoutingService { /** * Selects a candidate for blob allocation from the current list of available * storage nodes. */ selectStorageProvider( digest: MultihashDigest, size: number ): Promise<Result<Principal, CandidateUnavailable | Failure>> /** * Returns information required to make an invocation to the requested storage * node. */ configureInvocation<C extends BlobAllocate | BlobAccept>( provider: Principal, capability: C, options?: Omit<UCANOptions, 'audience'> ): Promise<Result<Configuration<C>, ProofUnavailable | Failure>> } ``` Tests implement a storage provider node and setup 2 nodes that are used in tests that the routing service picks randomly from. However the router will be sticky when asked to store the same blob multiple times. This allows existing tests for allocation and accept responses to pass. Note: we need to review if the semantics for allocate and accept responses really makes sense in a context where there are multiple storage providers (TLDR; the allocation size does not).
The store protocol in not compatible with decentralized storage as there are no "bucket events" on remote storage nodes.
🤖 I have created a release *beep* *boop* --- ## [1.0.3](access-v1.0.2...access-v1.0.3) (2025-02-11) ### Fixes * dedupe proofs ([#143](#143)) ([de2ac67](de2ac67)) * use up.storacha.network ([#144](#144)) ([ac6b5b4](ac6b5b4)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
🤖 I have created a release *beep* *boop* --- ## [1.1.2](cli-v1.1.1...cli-v1.1.2) (2025-02-11) ### Fixes * use up.storacha.network ([#144](#144)) ([ac6b5b4](ac6b5b4)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
🤖 I have created a release *beep* *boop* --- ## [1.0.5](upload-client-v1.0.4...upload-client-v1.0.5) (2025-02-11) ### Fixes * use correct object in cause ([#140](#140)) ([372f839](372f839)) * use up.storacha.network ([#144](#144)) ([ac6b5b4](ac6b5b4)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
🤖 I have created a release *beep* *boop* --- ## [1.1.5](client-v1.1.4...client-v1.1.5) (2025-02-11) ### Fixes * use up.storacha.network ([#144](#144)) ([ac6b5b4](ac6b5b4)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: ash <alan@storacha.network>
🤖 I have created a release *beep* *boop* --- ## [1.1.2](filecoin-api-v1.1.1...filecoin-api-v1.1.2) (2025-02-11) ### Fixes * use up.storacha.network ([#144](#144)) ([ac6b5b4](ac6b5b4)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: ash <alan@storacha.network>
🤖 I have created a release *beep* *boop* --- ## [1.3.4](upload-api-v1.3.3...upload-api-v1.3.4) (2025-02-11) ### Fixes * store w3s accept invocation ([#142](#142)) ([e0c509d](e0c509d)) * use up.storacha.network ([#144](#144)) ([ac6b5b4](ac6b5b4)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: ash <alan@storacha.network>
(But remove pointless lint tasks.) Among other things, this means that `nx watch --all` will watch files belonging to the root.
This just ends up littering empty JSDoc around.
* origin/main: chore(main): release upload-api 1.3.4 (#156) chore(main): release filecoin-api 1.1.2 (#155) chore(main): release client 1.1.5 (#154) chore(main): release upload-client 1.0.5 (#153) chore(main): release cli 1.1.2 (#152) chore(main): release access 1.0.3 (#151) chore(main): release capabilities 1.2.2 (#145) fix: store w3s accept invocation (#142) fix: dedupe proofs (#143) fix: use up.storacha.network (#144) fix: use correct object in cause (#140) Update CHANGELOG.md chore(main): release upload-api 1.3.3 chore(upload-api): add comment for clarity refactor(blob-registry): pass cause as a parameter to deregister
This means that both in CI and in `nx run-many`, it will use `list`, while running the task directly with `nx run` will use `html` and launch the browser to display the results.
(Whoops!)
TypeScript can take a directory name in its `include` field, but Nx also uses that to determine which files are inputs, for calculating the cache hash, and it *doesn't* support a directory name. Instead, it requires a full glob.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.