open-index/open-npm huggingface dataset:
npm package: @patricktree/codemod-rewrite-module-specifiers-to-full-paths
Description: Codemod to rewrite module specifiers of TypeScript files to their full paths.
Author: Patrick Kerschbaum
Latest version: 2.2.0

# `@patricktree/codemod-rewrite-module-specifiers-to-full-paths`

Codemod to rewrite module specifiers of TypeScript files to their full paths.

## Problem

Module specifiers for relative, absolute, and "subpath" (=path alias) imports in Node.js ESM need to be "exact".  
This is in contrast to Node.js CJS modules, which applied a "searching" algorithm when loading modules (see also <https://nodejs.org/api/modules.html#file-modules>).

For example, while the following `require` function calls were working in Node.js CJS modules, they are not working anymore in ESM modules:

```js
/* assuming ./some-directory/index.js is present */
require('./some-directory');
require('./some-directory/index');
```

Therefore, migrating CJS code to ESM code involves rewriting every module specifier to its full path.  
Doing this by hand is tedious and error-prone.

## Solution

This package is a codemod which consumes a TypeScript configuration file and rewrites all relative, absolute, and path alias imports to their full paths.

## How to use

```bash
npx @patricktree/codemod-rewrite-module-specifiers-to-full-paths --help

# Usage: codemod [options]

# Options:
#   --project <path-to-tsconfig-json>  Path to the TypeScript configuration file (e.g. "./tsconfig.json").
#   --basepath <path>                  A root directory to resolve relative path entries in the TypeScript config file to (e.g. option "outDir"). If omitted, the directory of the
#                                      TypeScript configuration file passed with "--project" is used.
#   -h, --help                         display help for command

# for example
npx @patricktree/codemod-rewrite-module-specifiers-to-full-paths --project=./path/to/tsconfig.json
```
npm package: @patricktree/pkg-consumption-test
Description: [![NPM version](https://img.shields.io/npm/v/@patricktree/pkg-consumption-test?color=a1b858&label=)](https://www.npmjs.com/package/@patricktree/pkg-consumption-test)
Author: Patrick Kerschbaum
Latest version: 1.0.4

# @patricktree/pkg-consumption-test

[![NPM version](https://img.shields.io/npm/v/@patricktree/pkg-consumption-test?color=a1b858&label=)](https://www.npmjs.com/package/@patricktree/pkg-consumption-test)

## Problem

You maintain a package which should be usable in a variety of project setups and JavaScript runtimes.  
Those "scenarios" could be:

- It should run in Node.js CJS modules.
- It should run in Node.js ESM modules.
- It should successfully compile in a TypeScript project.
- It should run in Browsers.
- It should run in Deno.
- ...

You want to test your package in those scenarios, but it is cumbersome to do the testing manually.

## Solution

This tool allows you to run automated tests for such "package consumption scenarios".  
It will

- Start a private package registry (using [Verdaccio](https://verdaccio.org/)).
- Publish your package into that registry.
- Run the "consumption scenarios", one by one. They will get your package installed from the private package registry.
- Stop the package registry.

This approach - using a package registry - will closely simulate the real-world experience of your package
consumers installing the package from `npmjs.com`.

## Setup

You can see how this tool was added to `tiny-invariant` in this pull request: [github.com/alexreardon/tiny-invariant#164](https://github.com/alexreardon/tiny-invariant/pull/164).

First, install the package:

```sh
npm add --save-dev @patricktree/pkg-consumption-test
```

Add a package.json script to run the package consumption scenarios:

```jsonc
{
  /* ... */
  "scripts": {
    "test:pkg-consumption": "pkg-consumption-test --packageName=\"tiny-invariant\" --pathToScenariosDirectory=\"./test-pkg-consumption-scenarios\"",
  },
}
```

At this point you can run `npm run test:pkg-consumption` and you will see that the package gets published to the private registry.

Only thing left is to add scenarios.  
For example, imagine you want to create a scenario which imports and runs the package in a Node.js ESM module:

1. Create the directory `test-pkg-consumption-scenarios/run-node-esm`.
1. Add the file `package.json`:

   ```json
   {
     "name": "run-node-esm",
     "dependencies": {
       "tiny-invariant": "*"
     }
   }
   ```

1. Add the file `src/test.mjs`:

   ```js
   import invariant from 'tiny-invariant';

   invariant(true);
   ```

1. Finally, you have to implement a `package.json` script called `execute-scenario`.
   This script will be run by `pkg-consumption-test`.  
   You can do there whatever you want - run Node.js, bundle the source with webpack, etc.  
   For the given scenario, we just execute the ESM file with Node.js:

   ```jsonc
   {
     /* ... */
     "scripts": {
       "execute-scenario": "node ./src/test.mjs",
     },
   }
   ```

Now, when you run `npm run test:pkg-consumption` in your package again, that scenario will get executed!
npm package: @patricktree/pkg-management
Description: ## Bins
Author: Patrick Kerschbaum
Latest version: 2.1.1

# `@patricktree/pkg-management`

## Bins

### Create a pnpm patch via `ts-patch`

Workaround for <https://github.com/pnpm/pnpm/issues/6111>:

```bash
pnpm --package=\"@patricktree/pkg-management\" dlx create-pnpm-patch-via-ts-patch --typescript-version=5.1.6
```
npm package: @patrickxu/use-loading
Description: @patrickxu/use-loading is a custom React hook effortlessly manages the loading state of asynchronous functions.
Author: patrickxunuo
Latest version: 0.0.5

# @patrickxu/use-loading 

@patrickxu/use-loading is a custom React hook effortlessly manages the loading state of asynchronous functions.

## Installation

To install @patrickxu/use-loading, simply run:

    npm install @patrickxu/use-loading

or

    yarn add @patrickxu/use-loading

## Usage

To use, simply import useLoading from @patrickxu/use-loading:

```jsx
import useLoading from '@patrickxu/use-loading';

const sleep = (millisecond = 500) => {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve(true);
    }, millisecond);
  });
}

const App = () => {
  const { groupHandler, isLoading } = useLoading();

  const asyncFunction = groupHandler(async () => {
    await sleep();
  }, "key 1");

  return (
    <>
      <button onClick={asyncFunction1}>
        sleep for 500ms ("key 1")
      </button>
      <span>
        {`isLoading: ${isLoading}`}
      </span>
    </>);
};
```
For a more detailed example, please refer to the CodeSandbox [demo](https://codesandbox.io/s/lingering-feather-93kw25).


## Documentation

### ActionType

```tsx
type ActionType = (...params: any[]) => Promise<any>;
```


### UseLoadingReturnType
```tsx
interface UseLoadingReturnType {
    // state indicating whether async function is running
    isLoading: boolean;
    // state indicating whether async function throws an error
    isError: boolean;
    // the handler returned if you pass an async function as input
    handleAction: ActionType;
    // the handler for multiple async function share the same loading state
    groupHandler: (fun: ActionType, key?: string) => ActionType;
    // the keys of async function that are running
    keys: string[];
}
```

## Contributing
If you'd like to contribute to @patrickxu/use-loading, feel free to submit a pull request or open an issue on GitHub. We welcome all contributions and feedback!