What is the best way to organize my NPM package with separate directories for types and functions?

Question

What is the best way to organize my NPM package with separate directories for types and functions?

I am currently working on developing a custom NPM package that will serve as a repository for sharing types and functions across my project. Let's name this project wordle. Given the emphasis on types, it is worth noting that I am using TypeScript for this project. My goal is to be able to import these types and functions in the following manner:

import { Move } from "wordle-shared/types";
import { getValidWords } from "wordle-shared/utils"

I would appreciate it if someone could guide me on how I should structure this NPM package to achieve the desired organization. I have noticed that some developers use @ in their package names (e.g. @wordle-shared), so I am open to incorporating that naming convention if necessary.

Currently, my folder structure looks like this:

wordle-shared
├── src
│   ├── types
│   └── utils
├── package.json
├── tsconfig.json
├── .gitignore

typescript npm package.json tsconfig monorepo

Answer 1

Answer №1

Have you considered utilizing npm workspaces for your project structure? This approach could help organize your packages in a way that aligns with your requirements, allowing each package to manage its dependencies and interact with others seamlessly.

// ./wordle/package.json
{
    "name": "wordle",
    "workspaces": [
        "wordle-shared",
        "wordle-project-a",
    ]
}

.
├── node_modules
│   ├── .package-lock.json
│   ├── wordle-project-a -> ../wordle-project-a
│   └── wordle-shared -> ../wordle-shared
├── package.json
├── package-lock.json
├── wordle-project-a
│   ├── package.json
│   └── src
│       └── index.ts
└── wordle-shared
    ├── package.json
    ├── types
    │   └── index.ts
    └── util
        └── index.ts

This configuration allows you to access wordle-shared's functionalities in wordle-project-a as needed. If you prefer segregating them into distinct src/ directories, consider setting up a path alias in tsconfig.json.

Answer 2

Have you considered utilizing npm workspaces for your project structure? This approach could help organize your packages in a way that aligns with your requirements, allowing each package to manage its dependencies and interact with others seamlessly.

// ./wordle/package.json
{
    "name": "wordle",
    "workspaces": [
        "wordle-shared",
        "wordle-project-a",
    ]
}

.
├── node_modules
│   ├── .package-lock.json
│   ├── wordle-project-a -> ../wordle-project-a
│   └── wordle-shared -> ../wordle-shared
├── package.json
├── package-lock.json
├── wordle-project-a
│   ├── package.json
│   └── src
│       └── index.ts
└── wordle-shared
    ├── package.json
    ├── types
    │   └── index.ts
    └── util
        └── index.ts

This configuration allows you to access wordle-shared's functionalities in wordle-project-a as needed. If you prefer segregating them into distinct src/ directories, consider setting up a path alias in tsconfig.json.

Answer 3

Answer №2

From what I know, in order for TypeScript to properly load your package, a build step is necessary because it expects to find d.ts files.

One alternative could be using git submodules to directly incorporate the library code into your project instead of deploying and installing it as a package. While I haven't personally tested this method or workspaces, I believe it would seamlessly integrate with TypeScript, eliminating the need to build while still keeping the library versioned.

Here is an example of setting up the package using tsc:

wordle-shared
├── src
│   ├── types.ts
│   └── utils.ts
├── dist
│   ├── types.d.ts
│   └── utils.js
│   └── utils.d.ts
├── package.json
├── tsconfig.json
├── .gitignore

// wordle-shared package.json
{
    "type": "module",
    "version": "1.0.0",
    "exports": {
        "./utils": {
            "import": "./dist/utils.js",
            "types": "./dist/utils.d.ts"
        }, "./types": {
            "types": "./dist/types.d.ts"
        }
    }
}

// wordle-shared tsconfing.json
{
    "compilerOptions": {
        "outDir": "./dist",
    },
    "include": ["src"],
}

// .gitignore
node_modules
dist

Afterwards, you can add the shared library as a dependency

// wordle package.json
{
  "dependencies": {
    "wordle-shared": "^1.0.0",
  }
}

Make sure to include this compiler option for TypeScript to recognize the types fields in the library's package.json

// wordle tsconfing.json
{
    "compilerOptions": {
        "moduleResolution": "nodenext"
    },
}

Answer 4

From what I know, in order for TypeScript to properly load your package, a build step is necessary because it expects to find d.ts files.

One alternative could be using git submodules to directly incorporate the library code into your project instead of deploying and installing it as a package. While I haven't personally tested this method or workspaces, I believe it would seamlessly integrate with TypeScript, eliminating the need to build while still keeping the library versioned.

Here is an example of setting up the package using tsc:

wordle-shared
├── src
│   ├── types.ts
│   └── utils.ts
├── dist
│   ├── types.d.ts
│   └── utils.js
│   └── utils.d.ts
├── package.json
├── tsconfig.json
├── .gitignore

// wordle-shared package.json
{
    "type": "module",
    "version": "1.0.0",
    "exports": {
        "./utils": {
            "import": "./dist/utils.js",
            "types": "./dist/utils.d.ts"
        }, "./types": {
            "types": "./dist/types.d.ts"
        }
    }
}

// wordle-shared tsconfing.json
{
    "compilerOptions": {
        "outDir": "./dist",
    },
    "include": ["src"],
}

// .gitignore
node_modules
dist

Afterwards, you can add the shared library as a dependency

// wordle package.json
{
  "dependencies": {
    "wordle-shared": "^1.0.0",
  }
}

Make sure to include this compiler option for TypeScript to recognize the types fields in the library's package.json

// wordle tsconfing.json
{
    "compilerOptions": {
        "moduleResolution": "nodenext"
    },
}

What is the best way to organize my NPM package with separate directories for types and functions?

Answer №1

Answer №2

Similar questions

Attempting to create a promise for a dropdown menu in React-Select

The button fails to log any text to the developer console

What is the best way to perform type checking for a basic generic function without resorting to using a cumbersome cast

Storing multiple email addresses in an array using an HTML input element

Is the parameter rejecting the use of orderBy for 'startTime'?

Can a condition be incorporated in a gulpfile to execute a task depending on the size of a file?

Encountering an issue when trying to generate a build in Angular 5

Is there a way to create 32-bit binaries on a 64-bit system using npm?

The post-installation script within the package.json file is a critical component

Should the package for icons in the library I'm constructing be categorized under dependencies or devDependencies?

Leveraging node modules in the browser using browserify - Error: fileType is not recognized

Enhance Angular Forms: Style Readonly Fields in Grey and Validate Data Retrieval using Typescript

"Encountering issues with Firebase deployment related to function-builder and handle-builder while working with TypeScript

Converting language into class components using ngx-translate in Angular

Getting Session from Next-Auth in API Route: A Step-by-Step Guide

Refresh Material-Ui's Selection Options

Concealing the sidebar in React with the help of Ant Design

The challenge of validating in Typescript and utilizing type inference

Having trouble locating the TypeScript compiler in Visual Studio 2017?

Is it possible to use square brackets in conjunction with the "this" keyword to access a class property using an expression?