TypeScript plugin doesn't find buildable project without `exports["."]`

[fregante]

Current Behavior

#29670 was not fixed

This bug exists since Nx 20.3 and has blocked us from upgrading. Our exports generally looks like this:

  "exports": {
    "./package.json": "./package.json",
    "./*.js": "./dist/*.js",
    "./*": "./src/*"
  },

and build is not inferred unless I add an . entry point. In our repo only a handful of packages have that entry point. nx show projects --with-target build essentially produces a list of packages that either lack exports or specify .

nx.json has this config, which matches the one on https://nx.dev/technologies/typescript/introduction

  "plugins": [
    {
      "plugin": "@nx/js/typescript",
      "options": {
        "build": {
          "configName": "tsconfig.lib.json"
        }
      }
    }
  ],

My solution was to add a fictitious entry point that satisfies Nx and points to this bug:

  "exports": {
    "./package.json": "./package.json",
    "./*.js": "./dist/*.js",
    "./*": "./src/*",
+   ".": "./dist/https://github.com/nrwl/nx/issues/29670"
  },

Expected Behavior

build should be inferred even with packages that lack an . exports

GitHub Repo

No response

Steps to Reproduce

1. Create Nx monorepo with one TS library
2. Specify "exports": {"./*.js", "./dist/*.js"}
3. Run nx build the-lib and see it fail because build doesn't exist

Nx Report

Node           : 22.18.0
OS             : darwin-arm64
Native Target  : aarch64-macos
npm            : 10.9.3

nx             : 21.3.11
@nx/js         : 21.3.11
@nx/eslint     : 21.3.11
@nx/workspace  : 21.3.11
@nx/devkit     : 21.3.11
typescript     : 5.9.2
---------------------------------------
Registered Plugins:
@nx/js/typescript
@nx/eslint/plugin
./scripts/nx/jest-plugin.ts
./scripts/nx/vitest-plugin.ts
---------------------------------------
Cache Usage: 455.18 KB / 92.64 GB

Failure Logs

Package Manager Version

No response

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

No response

[fregante]

I'm not sure why this logic exists at all. The whole purpose of tsconfig.lib.json is to define a subset of files that are meant to be built and exported for use in other packages. If the file exists, then build should be defined, no extra conditions needed.

If I didn't want/need build, then I'd delete tsconfig.lib.json

[leosvelperez]

Thanks for reporting this!

Could you provide an exact reproduction? I couldn't reproduce the issue following these steps based on the information you provided:

• npx -y create-nx-workspace@latest --nx-cloud=skip foo
  
   NX   Let's create a new workspace [https://nx.dev/getting-started/intro]
  
  ✔ Which stack do you want to use? · none
  ✔ Would you like to use Prettier for code formatting? · No

• npx nx g lib packages/pkg1
  
   NX  Generating @nx/js:library
  
  ✔ Which bundler would you like to use to build the library? Choose 'none' to skip build setup. · tsc
  ✔ Which linter would you like to use? · none
  ✔ Which unit test runner would you like to use? · none

• Replace generate exports in packages/pkg1/package.json with:

  "exports": {
    "./package.json": "./package.json",
    "./*.js": "./dist/*.js",
    "./*": "./src/*"
  },

• Verify build task:

  npx nx show projects --with-target build
  @qux/pkg1

I also made sure to use the same versions you're using for everything. My nx report looks exactly like the one you posted.

---

I'm not sure why this logic exists at all. The whole purpose of tsconfig.lib.json is to define a subset of files that are meant to be built and exported for use in other packages. If the file exists, then build should be defined, no extra conditions needed.

If I didn't want/need build, then I'd delete tsconfig.lib.json

Nx has the concept of non-buildable libraries, which are bundled with a main project when using a bundler that supports bundling code. For those libraries, you would still have a tsconfig.lib.json that includes the library runtime files. This is used by the IDE and potentially by the bundler if it correctly handles TS project references. That's why this logic is in place.

We could consider including a flag in the plugin to bypass this logic in workspaces where users choose to. It could be helpful in cases where all libraries are meant to be built independently and could potentially improve the plugin perf as well by reducing the operations it performs.

[fregante]

I couldn't reproduce the issue following these steps based on the information you provided:

Sorry about that, I'll try to debug Nx' code and see why it's losing track of these libs.

For those libraries, you would still have a tsconfig.lib.json that includes the library runtime files. This is used by the IDE and potentially by the bundler if it correctly handles TS project references. That's why this logic is in place.

Why isn't tsconfig.json enough in this case? They're not built, they're just typechecked

[fregante]

I don't know why the suggested repro steps aren't enough, but the issue in the title is explicitly defined by this piece of code, which is where I can see it return false when I drop my .

nx/packages/js/src/plugins/typescript/util.ts

Lines 210 to 227 in 9ffd6da

	// Check the `.` export if `exports` is defined.
	if (exports) {
	if (typeof exports === 'string') {
	return !isPathSourceFile(exports);
	}
	if (typeof exports === 'object' && '.' in exports) {
	return !containsInvalidPath(exports['.']);
	}
	// Check other exports if `.` is not defined or valid.
	for (const key in exports) {
	if (key !== '.' && containsInvalidPath(exports[key])) {
	return false;
	}
	}
	return true;
	}

The code says: if any of the exports contains an invalid path, then return false

But it should be instead: if none of the paths points to distribution, then return false

[fregante]

I added a couple of logs for a specific project:

projectRoot.includes('data-access-base') && console.log('checking', key, exports[key])
if (key !== '.' && containsInvalidPath(exports[key])) {
    projectRoot.includes('data-access-base') && console.log('false')
    return false;
}

Here's the output:

checking ./package.json ./package.json
checking ./*.js ./distribution/*.js
checking ./* ./src/*
false
checking ./package.json ./package.json
checking ./*.js ./distribution/*.js
checking ./* ./src/*
false

if I specify ".": "./distribution/https://github.com/nrwl/nx/issues/32290" this condition is not reached at all.

That linked snippet should be changed to this, which works in my case

if (exports) {
    if (typeof exports === 'string') {
        return !isPathSourceFile(exports);
    }

    return Object.values(exports).some((value) => !containsInvalidPath(value));
}