6

I'm publishing an npm package named foo to the npm registry. I wrote the package using a compile-to-js language. For sanity, I put the compiled output into the dist/ folder of the project directory. My package.json lists the entrypoint as dist/entry.js:

{
  "name": "foo",
  "main": "dist/entry.js",
}

Sometimes, I want to use files within the package that are not part of the entry point. For example, there is a very useful export called whatever inside of dist/util.js:

import { whatever } from "foo/dist/util";

This works, but forcing the users of my package to type dist/ in all import statements is inconvenient.

Furthermore, re-exporting every possible util function is not DRY. I do not want to re-export from the entrypoint.

Ideally, I would like to import files from dist/ using the following syntax:

import { whatever } from "foo/util"

How do I configure my package.json to search for files in the dist/ folder of my project?

E_net4
  • 27,810
  • 13
  • 101
  • 139
Rick
  • 8,366
  • 8
  • 47
  • 76
  • I cannot understand what is the problem with re-exporting. If you have a very good util that is not a logical part of your library then you should post it as a separate library and use it as dependency. If it is a logical part of your library then it should be shipped together with the library. What's bad in having a single entry point to all your library's API? – smnbbrv Jul 31 '18 at 20:59

1 Answers1

3

This cannot be done.

This is the reason why some packages have entry point file that re-exports all public exports (not everything that resides in dist is intended to be used by end user), e.g. @angular/core.

And the reason why some packages have unsuitable file structure that is published to NPM registry and favours proper import paths, e.g. rxjs.

Estus Flask
  • 206,104
  • 70
  • 425
  • 565