New Case Study:See how Anthropic automated 95% of dependency reviews with Socket.Learn More →
@upstash/ratelimit
Advanced tools
@upstash/ratelimit - npm Package Compare versions
Comparing version 1.1.2 to 1.1.3
@@ -351,3 +351,17 @@ "use strict"; | ||
| }).catch((err) => { | ||
| console.warn("Failed to record analytics", err); | ||
| let errorMessage = "Failed to record analytics"; | ||
| if (`${err}`.includes("WRONGTYPE")) { | ||
| errorMessage = ` | ||
| Failed to record analytics. See the information below: | ||
| This can occur when you uprade to Ratelimit version 1.1.2 | ||
| or later from an earlier version. | ||
| This occurs simply because the way we store analytics data | ||
| has changed. To avoid getting this error, disable analytics | ||
| for *an hour*, then simply enable it back. | ||
| `; | ||
| } | ||
| console.warn(errorMessage, err); | ||
| }); | ||
@@ -1198,7 +1212,9 @@ res.pending = Promise.all([res.pending, analyticsP]); | ||
| async resetTokens(ctx, identifier) { | ||
| const pattern = [identifier, "*"].join(":"); | ||
| if (!ctx.cache) { | ||
| throw new Error("This algorithm requires a cache"); | ||
| } | ||
| ctx.cache.pop(identifier); | ||
| const bucket = Math.floor(Date.now() / windowDuration); | ||
| const key = [identifier, bucket].join(":"); | ||
| ctx.cache.pop(key); | ||
| const pattern = [identifier, "*"].join(":"); | ||
| await ctx.redis.eval(resetScript, [pattern], [null]); | ||
@@ -1205,0 +1221,0 @@ } |
@@ -1,1 +0,1 @@ | ||
| { "name": "@upstash/ratelimit", "version": "v1.1.2", "main": "./dist/index.js", "types": "./dist/index.d.ts", "files": [ "dist" ], "scripts": { "build": "tsup", "test": "bun test src --coverage", "fmt": "bunx @biomejs/biome check --apply ./src" }, "devDependencies": { "@upstash/redis": "^1.28.3", "bun-types": "latest", "rome": "^11.0.0", "turbo": "^1.10.15", "tsup": "^7.2.0", "typescript": "^5.0.0" }, "dependencies": { "@upstash/core-analytics": "^0.0.8" }, "license": "MIT" } | ||
| { "name": "@upstash/ratelimit", "version": "v1.1.3", "main": "./dist/index.js", "types": "./dist/index.d.ts", "files": [ "dist" ], "scripts": { "build": "tsup", "test": "bun test src --coverage", "fmt": "bunx @biomejs/biome check --apply ./src" }, "devDependencies": { "@upstash/redis": "^1.28.3", "bun-types": "latest", "rome": "^11.0.0", "turbo": "^1.10.15", "tsup": "^7.2.0", "typescript": "^5.0.0" }, "dependencies": { "@upstash/core-analytics": "^0.0.8" }, "license": "MIT" } |
| # Upstash Rate Limit | ||
| [](https://www.npmjs.com/package/@upstash/ratelimit) | ||
| [](https://github.com/upstash/ratelimit/actions/workflows/tests.yaml) | ||
| [](https://www.npmjs.com/package/@upstash/ratelimit) | ||
@@ -72,81 +72,10 @@ > [!NOTE] > **This project is in GA Stage.** | ||
| For Cloudflare Workers and Fastly Compute@Edge, you can use the following imports: | ||
| For more information on getting started, you can refer to [our documentation](https://upstash.com/docs/oss/sdks/ts/ratelimit/gettingstarted). | ||
| ```ts | ||
| import { Redis } from "@upstash/redis/cloudflare"; // for cloudflare workers and pages | ||
| import { Redis } from "@upstash/redis/fastly"; // for fastly compute@edge | ||
| ``` | ||
| [Here's a complete nextjs example](https://github.com/upstash/ratelimit/tree/main/examples/nextjs) | ||
| The `limit` method returns some more metadata that might be useful to you: | ||
| ## Documentation | ||
| ````ts | ||
| export type RatelimitResponse = { | ||
| /** | ||
| * Whether the request may pass(true) or exceeded the limit(false) | ||
| */ | ||
| success: boolean; | ||
| /** | ||
| * Maximum number of requests allowed within a window. | ||
| */ | ||
| limit: number; | ||
| /** | ||
| * How many requests the user has left within the current window. | ||
| */ | ||
| remaining: number; | ||
| /** | ||
| * Unix timestamp in milliseconds when the limits are reset. | ||
| */ | ||
| reset: number; | ||
| See [the documentation](https://upstash.com/docs/oss/sdks/ts/ratelimit/overview) for more information details about this package. | ||
| /** | ||
| * For the MultiRegion setup we do some synchronizing in the background, after returning the current limit. | ||
| * Or when analytics is enabled, we send the analytics asynchronously after returning the limit. | ||
| * In most case you can simply ignore this. | ||
| * | ||
| * On Vercel Edge or Cloudflare workers, you need to explicitly handle the pending Promise like this: | ||
| * | ||
| * ```ts | ||
| * const { pending } = await ratelimit.limit("id") | ||
| * context.waitUntil(pending) | ||
| * ``` | ||
| * | ||
| * See `waitUntil` documentation in | ||
| * [Cloudflare](https://developers.cloudflare.com/workers/runtime-apis/handlers/fetch/#contextwaituntil) | ||
| * and [Vercel](https://vercel.com/docs/functions/edge-middleware/middleware-api#waituntil) | ||
| * for more details. | ||
| * ``` | ||
| */ | ||
| pending: Promise<unknown>; | ||
| }; | ||
| ```` | ||
| ### Docs | ||
| See [the documentation](https://upstash.com/docs/oss/sdks/ts/ratelimit/overview) for more information details. | ||
| ### Using with CloudFlare Workers and Vercel Edge | ||
| When we use CloudFlare Workers and Vercel Edge, we need to be careful about | ||
| making sure that the rate limiting operations complete correctly before the runtime ends | ||
| after returning the response. | ||
| This is important in two cases where we do some operations in the backgroung asynchronously after `limit` is called: | ||
| 1. Using MultiRegion: synchronize Redis instances in different regions | ||
| 2. Enabling analytics: send analytics to Redis | ||
| In these cases, we need to wait for these operations to finish before sending the response to the user. Otherwise, the runtime will end and we won't be able to complete our chores. | ||
| In order to wait for these operations to finish, use the `pending` promise: | ||
| ```ts | ||
| const { pending } = await ratelimit.limit("id"); | ||
| context.waitUntil(pending); | ||
| ``` | ||
| See `waitUntil` documentation in [Cloudflare](https://developers.cloudflare.com/workers/runtime-apis/handlers/fetch/#contextwaituntil) and [Vercel](https://vercel.com/docs/functions/edge-middleware/middleware-api#waituntil) for more details. | ||
| ## Contributing | ||
@@ -161,4 +90,18 @@ | ||
| To run the tests, you will need to set some environment variables. Here is a list of | ||
| variables to set: | ||
| - `UPSTASH_REDIS_REST_URL` | ||
| - `UPSTASH_REDIS_REST_TOKEN` | ||
| - `US1_UPSTASH_REDIS_REST_URL` | ||
| - `US1_UPSTASH_REDIS_REST_TOKEN` | ||
| - `APN_UPSTASH_REDIS_REST_URL` | ||
| - `APN_UPSTASH_REDIS_REST_TOKEN` | ||
| - `EU2_UPSTASH_REDIS_REST_URL` | ||
| - `EU2_UPSTASH_REDIS_REST_TOKEN` | ||
| You can create a single Upstash Redis and use its URL and token for all four above. | ||
| Once you set the environment variables, simply run: | ||
| ```sh | ||
| UPSTASH_REDIS_REST_URL=".." UPSTASH_REDIS_REST_TOKEN=".." pnpm test | ||
| pnpm test | ||
| ``` |
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
New alerts
Manifest confusion
Supply chain riskThis package has inconsistent metadata. This could be malicious or caused by an error when publishing the package.
Found 1 instance in 1 package
Fixed alerts
Manifest confusion
Supply chain riskThis package has inconsistent metadata. This could be malicious or caused by an error when publishing the package.
Found 1 instance in 1 package
Improved metrics
- Total package byte prevSize
- increased by0.27%
275857
- Lines of code
- increased by0.9%
2902
Worsened metrics
- Number of lines in readme file
- decreased by-34.97%
106
No dependency changes