Package.json with multiple entrypoints

Question

I have a library which was used as follows

import { Foo } from '@me/core';
const foo = new Foo();

The package.json of that library looks like

"name": "@me/core",
"version": "1.0.0",
"main": "dist/index.js",
"types": "dist/index.d.ts",
"license": "MIT",
...

With dist/index.js its entrypoint. Now, however, I would provide an import for NodeJs projects only and one for web projects. Ideally I would have something like this for NodeJs

import { Foo } from '@me/core/nodejs';

and if you're working on a web-project you could do

import { Foo } from '@me/core/web';

My understanding is that both @me/core/nodejs and @me/core/web will be different NPM packages this way, which is not what I want. I want it to be in 1 npm package.

I tried to changed the library's index.ts file, from

export * from './foo';

into

import * as nodejs from './nodejs';
import * as web from './web';

export { web, nodejs };

This actually works, but I have to use it now (in a NODEJS project) as follows

import { nodejs } from '@me/core';

const foo = new nodejs.Foo();

Is there maybe a way to import this such that I don't need the nodejs everytime?

As you can see I'm not so sure what I should do here so any help would be appreciated!

UPDATE: Based on the suggestions by @Klaycon I see the following error:

Answer 1

As you're using ECMAScript modules, please refer to node.js docs on package entry points :

In a package's package.json file, two fields can define entry points for a package: "main" and "exports". The "main" field is supported in all versions of Node.js, but its capabilities are limited: it only defines the main entry point of the package.
The "exports" field provides an alternative to "main" where the package main entry point can be defined while also encapsulating the package, preventing any other entry points besides those defined in "exports". This encapsulation allows module authors to define a public interface for their package.

So, in your package.json, you could define exports like this:

  "main": "dist/index.js",
  "exports": {
    ".": "dist/index.js",
    "./nodejs": "dist/nodejs",
    "./web": "dist/web",
  }

Answer 2

The accepted answer, using the exports field, is one way to do it, but not the only way -- and as you've found, isn't currently supported by Typescript.

Look at the @angular/material package, which works similarly to what you have in mind. In @angular/material/package.json , you've got a module field that points to an empty JS file, and a typings field that points to an empty .d.ts file. But you've also got @angular/material/button/package.json which points (indirectly) to the implementation of MatButton (and a bunch of other stuff). When you import {MatButton} from "@angular/material/button" , it resolves this package file, looks at its module and typings fields, and uses those to resolve the runtime code and exported types, respectively.

You could do the same thing: @me/core/package.json would have module and typings fields that point to empty files; @me/core/node/package.json would point to code for your Node-specific Foo class, and @me/core/web/package.json would point to code for your browser version of Foo .

Answer 3

Try to add the following code to the tsconfig.json :

{
  "compilerOptions": {
    "moduleResolution": "NodeNext"
  }
}

And then you can import the module like this:

import { Foo } from '@me/core/nodejs';

If you Don't Want to Touch the tsconfig.json you can use the following for the import:

import { Foo } from '@me/core/dist/nodejs';

References

• Package entry points
• Support for NodeJS 12.7+ package exports
• A Proposal For Module Resolution