rollupmonorepoyarn-workspacesnx.dev

Unable to resolve secondary entry points with additionalEntryPoints in nx workspace


I'm trying to add secondary entry points to my package builds, as described here. I'm using rollup, and I'm aware this tutorial is specifically for tsc, but it links to another tutorial for rollup here that references the exact same options. This tutorial is relevant to >v16.8 and I'm using v17.1.2.

I'm using a very simplistic structure for now. My directory structure is:

.
├── README.md
├── jest.config.ts
├── node_modules
├── package.json
├── project.json
├── rollup.config.ts
├── src
│   ├── index.ts
│   └── utils
│       ├── index.ts
│       ├── msal.ts
│       └── store.ts
├── tsconfig.json
├── tsconfig.lib.json
└── tsconfig.spec.json

I've added additionalEntryPoints to my project.json like so:

{
  "name": "@my-org/core",
  "$schema": "../../node_modules/nx/schemas/project-schema.json",
  "sourceRoot": "packages/core/src",
  "projectType": "library",
  "targets": {
    "build": {
      "executor": "@nx/rollup:rollup",
      "outputs": ["{options.outputPath}"],
      "options": {
        "outputPath": "dist/packages/core",
        "main": "packages/core/src/index.ts",
        "tsConfig": "packages/core/tsconfig.lib.json",
        "assets": [],
        "project": "packages/core/package.json",
        "compiler": "swc",
        "format": ["cjs", "esm"],
        "additionalEntryPoints": [
          "packages/core/src/utils/index.ts"
        ],
        "generateExportsField": true
      }
    },
    "lint": {
      "executor": "@nx/eslint:lint",
      "outputs": ["{options.outputFile}"],
      "options": {
        "lintFilePatterns": [
          "packages/core/**/*.ts",
          "packages/core/package.json"
        ]
      }
    },
    "test": {
      "executor": "@nx/jest:jest",
      "outputs": ["{workspaceRoot}/coverage/{projectRoot}"],
      "options": {
        "jestConfig": "packages/core/jest.config.ts"
      }
    }
  },
  "tags": []
}

And I've added the following to my package.json (in the package):

"exports": {
  "./utils": "./src/utils/index.js"
},

When I run nx build from my package directory, I get:

Error during bundle: Error: Could not resolve entry module (packages/core/src/utils/index.ts).

According to my directory structure, the file definitely exists. Any ideas on why might this be failing to recognize the file?


Solution

  • So it turns out I was doing a couple things wrong.

    First, after watching the video on https://nx.dev/recipes/tips-n-tricks/compile-multiple-formats for clues, I noticed he was running all the commands from the root of the workspace. So instead of running nx build from packages/core, I needed to be running nx build @my-org/core from the root of the workspace. I see no mention of this gotcha in the docs, so it'd be nice to see that note added somewhere in the guides.

    Second, after running the command from the root, I started getting this output:

    nx build @my-org/core
    
    > nx run @my-org/core:build
    
    Bundling @my-org/core...
      index.cjs.js 641 Bytes
      index.esm.js 548 Bytes
    ⚡ Done in 0.93s
    

    Cool, I thought, no error. But why am I not seeing utils in the output? Shouldn't that be derived from the exports section in the package.json? Nope, apparently the additionalEntryPoints options just takes the exact file name and adds that instead. So since index is already named in the main export, utils/index seems to be interpreted as a duplicate. I figured since the instructions include explicitly naming the exports in the package.json, that the exports would be named according to what you manually configure. But they instead seem to be implicitly derived from the file names you include in additionalEntryPoints, and from what I can tell, seem to be overridden. So if this is correct, this means the exports in package.json are unnecessary since additionalEntryPoints just overwrites them and ignores anything you put there. Another time wasting gotcha that isn't documented, so I'd love to see that note added as well. Unless I'm making some incorrect assumptions.

    Anyway, after moving all my export-name/index.ts files to simply export-name.ts in the root, I got it working. Hope my headache saves someone else a cracked computer screen.