open-index/open-npm huggingface dataset:
npm package: @janvdt/eslint-config-react-native
Description: ```javascript // install dependencies in your project yarn add --dev eslint prettier yarn add --dev @janvdt/eslint-config-react-native
Latest version: 1.0.1

# @entertainment-content-experience/eslint-config-frontend

```javascript
// install dependencies in your project
yarn add --dev eslint prettier
yarn add --dev @janvdt/eslint-config-react-native

// .eslintrc.js
module.exports = {
  root: true,
  extends: '@janvdt/eslint-config-react-native',
  parserOptions: {
    project: './tsconfig.json',
  },
};
npm package: @janvik/ev-components
Description: This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.
Latest version: 1.0.13

# React + TypeScript + Vite

This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.

Currently, two official plugins are available:

- [@vitejs/plugin-react](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/README.md) uses [Babel](https://babeljs.io/) for Fast Refresh
- [@vitejs/plugin-react-swc](https://github.com/vitejs/vite-plugin-react-swc) uses [SWC](https://swc.rs/) for Fast Refresh

## Expanding the ESLint configuration

If you are developing a production application, we recommend updating the configuration to enable type aware lint rules:

- Configure the top-level `parserOptions` property like this:

```js
export default tseslint.config({
  languageOptions: {
    // other options...
    parserOptions: {
      project: ['./tsconfig.node.json', './tsconfig.app.json'],
      tsconfigRootDir: import.meta.dirname,
    },
  },
})
```

- Replace `tseslint.configs.recommended` to `tseslint.configs.recommendedTypeChecked` or `tseslint.configs.strictTypeChecked`
- Optionally add `...tseslint.configs.stylisticTypeChecked`
- Install [eslint-plugin-react](https://github.com/jsx-eslint/eslint-plugin-react) and update the config:

```js
// eslint.config.js
import react from 'eslint-plugin-react'

export default tseslint.config({
  // Set the react version
  settings: { react: { version: '18.3' } },
  plugins: {
    // Add the react plugin
    react,
  },
  rules: {
    // other rules...
    // Enable its recommended rules
    ...react.configs.recommended.rules,
    ...react.configs['jsx-runtime'].rules,
  },
})
```
npm package: @janwilmake/dofetch
Description: > WIP: May still be unstable.
Latest version: 0.0.1

# `doFetch` Distributed Fetch Through Durable Objects

> WIP: May still be unstable.

`doFetch` alleviates Cloudflare limits of 1000 max requests and 6 concurrent requests in a worker. It does this using nested durable objects. The API is simple:

```ts
import { RecursiveFetcherEnv, doFetch, RecursiveFetcherDO } from "dofetch";
export { RecursiveFetcherDO };
interface Env extends RecursiveFetcherEnv {
  SECRET: string;
}

export default {
  fetch: async (request: Request, env: Env) => {
    const responses = await doFetch({
      env,
      requests: [
        { url: "xyz" },
        { url: "xyz", method: "POST" },
        { url: "xyz", headers: { accept: "application/json" } },
      ],
      // optional: set a ratelimit, e.g. 500 per minute
      rps: 500,
      windowDuration: 60000,
    });

    return new Response(JSON.stringify(responses));
  },
};
```

For `do-store`: There seems to be a bug now that, sometimes, it doesn't process all. With https://recursive-fetcher-do.githuq.workers.dev/?secret=******&max=1050 it randomly shows 200: 1050 or 200:1000. Strange cap!

I've chosen to store the results in the same DO as they are fetched, because this will allow for the highest possible ratelimit. May be changed in the future.

Notes: Depending on your desired concurrency, in development this is very slow with large sets of requests, but in prod it's faster.
npm package: @janwirth/b2b
Description: ✨ Write tests in human language (Gherkin) and verify program behavior with headless browser automation (Puppeteer).
Latest version: 0.0.17

# B2B 🎛️🎚️🎛️

✨ Write tests in human language (Gherkin) and verify program behavior with headless browser automation (Puppeteer).

🚀 Easy setup. No test-ids needed in your html - it reads the page like a human.

![Demo](https://media3.giphy.com/media/v1.Y2lkPTc5MGI3NjExazBmem53ZGg0OW5jY2lwYXY0Nzl5NncyamlsNXV2ZmxtMDMzdDczMCZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/5TCesEg1W2NHsWenYI/giphy.gif)

## Quick Start

1. 🌐 Start a server on localhost:3000
2. ⚡ Run `bun x @janwirth/b2b init`
   This will create an example feature file:

   ```gherkin
   Feature: Example

   Scenario: Example
     When I open localhost:3000
     Then I see "Hello, World!"
   ```

3. 👀 Run `bun x @janwirth/b2b watch` to start interactive mode
4. ✅ Run `bun x @janwirth/b2b run` to run all features

![Watch mode](https://media4.giphy.com/media/v1.Y2lkPTc5MGI3NjExNHBrcGVuMjg5ODF0OWdiMDE4emlzbjZvemNscWsxcXM0NXp2emZqaSZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/U8YmUzgsHpysM1LExG/giphy.gif)

## Use Cases

- 🛡️ **Quality Assurance**: Prevent regression bugs. Avoid the "two steps forward, one step back" problem.

- 🗺️ **Design Handoff via (Happy) Path Mapping**: Map user journeys through UI designs. Gherkin files mirror design complexity and reveal user effort required.

- 🤝 **Client Handoff**: Demonstrate functionality with executable specifications. Clients see exactly how features work; requirement changes reflect immediately in test scenarios.

- 🤖 **AI-Assisted Engineering**: Natural language test scenarios work well with AI tools like Cursor. Unit tests fall short for long-running processes and UI testing. The structured Gherkin format helps AI understand requirements and suggest improvements.

## Features

- 📝 Feature parser
- 🏷️ Annotations `@skip` and `@focus`
- 📹 Screen recordings and failure screenshots
- 👀 Watch mode
- 🎯 Content-based element finding
- 👁️ OCR image processing

## Perspectives

- 🎬 Effortlessly record product demos for marketing purposes using the latest UI

## Creating new Features

I used this prompt to generate the mock reset step:

```
Let's use @tdd.mdc to create a new feature.

We need to have a step that pings an endpoint to reset the application for a testable state (clearing test-created data etc.)

The @mock-server.ts  should have some isCleared variable that is visible in an endpoint so that the test runner can verify it with I see

When I open localhost:3000/reset-status
Then I see "stale data"
When I ping localhost:3000/reset
And I reload
Then I see "cleared"
```
npm package: @janya_03/mcp-forwarder
Description: MCP forwarder for Claude
Latest version: 1.0.4

# @smacient/mcp-forwarder

> Claude-compatible MCP forwarder — send JSON-RPC requests to your Cloud Run MCP proxy.

## Usage

```bash
npx @smacient/mcp-forwarder --url https://your-cloud-run-url.run.app
```

Claude config:

```json
{
  "GA4": {
    "command": "npx",
    "args": ["@smacient/mcp-forwarder", "--url", "https://your-cloud-run-url.run.app"],
    "env": {
      "MCP_JWT": "your-token"
    }
  }
}
```

## Author

[Smacient](https://smacient.com)