Path map problem with monorepo (ts-pack)

[sawa-ko]

I am currently using a monorepo system together with @moonrepo, so moonrepo synchronizes the paths of all the projects where I use other projects, and the structure looks like this:

{
  "extends": "../../tsconfig.base.json",
  "include": [
    "**/*"
  ],
  "compilerOptions": {
    "outDir": "../../.moon/cache/types/packages/client",
    "tsBuildInfoFile": "./dist/tsbuildinfo",
    "paths": {
      "@naeko/services": [
        "../services/src/index.ts"
      ],
      "@naeko/services/*": [
        "../services/src/*"
      ]
    }
  },
  "references": [
    {
      "path": "../services"
    }
  ]
}

Then I also install as a dependency the project that is used in the current project to be compiled:

{
  "name": "@naeko/client",
  "version": "0.0.1",
  "description": "asdsad",
  "license": "UNLICENSED",
  "private": true,
  "files": [
    "dist",
    "package.json"
  ],
  "type": "module",
  "main": "./dist/cjs/index.cjs",
  "module": "./dist/esm/index.mjs",
  "types": "./dist/@types/index.d.ts",
  "exports": {
    ".": {
      "import": "./dist/esm/index.mjs",
      "require": "./dist/cjs/index.cjs",
      "types": "./dist/@types/index.d.ts"
    }
  },
  "devDependencies": {
    "@lexedwards/ts-pack": "^1.3.2",
    "@types/node": "^20.4.3",
    "rimraf": "^5.0.1",
    "rome": "^12.1.3",
    "tslib": "^2.6.0",
    "typescript": "^5.1.6"
  },
  "ts-pack": {
    "inputFile": "src/index.ts",
    "tsConfig": "tsconfig.json",
    "bundle": false,
    "external": []
  },
  "dependencies": {
    "@naeko/services": "workspace:*"
  }
}

This is how I use it in my code:

import { name } from '@naeko/services';
console.log(name);

The problem is that ts-pack when compiling resolves me the package "@naeko/service" as path, then the compiled file becomes:

// dist/index.mjs
import{name as o}from"../../services/src/index";console.log(o);

Which is incorrect because I don't need it to resolve the path, since I already installed the project as a dependency in the project to compile, so now it throws the following error:

 *  Ejecutando tarea: c:\Users\inmor\OneDrive\Documentos\Personal\naeko-bot\node_modules\@moonrepo\cli\moon.exe run client:start 

▪▪▪▪ client:start
node:internal/errors:496
    ErrorCaptureStackTrace(err);
    ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find module 'c:\Users\inmor\OneDrive\Documentos\Personal\naeko-bot\packages\client\services\src\index' imported from c:\Users\inmor\OneDrive\Documentos\Personal\naeko-bot\packages\client\dist\esm\index.mjs
    at new NodeError (node:internal/errors:405:5)
    at finalizeResolution (node:internal/modules/esm/resolve:225:11)
    at moduleResolve (node:internal/modules/esm/resolve:837:10)
    at defaultResolve (node:internal/modules/esm/resolve:1035:11)
    at DefaultModuleLoader.resolve (node:internal/modules/esm/loader:251:12)
    at DefaultModuleLoader.getModuleJob (node:internal/modules/esm/loader:140:32)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:76:33)
    at link (node:internal/modules/esm/module_job:75:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}

And this is because the path that ts-pack put is the path to the original .ts file of the project. How can I make ts-pack not to change the import for this route? When I compile with tsc using the same tsconfig.json file configuration this behavior does not happen.

[lexedwards]

Hi,

Thanks for leaving such a detailed issue! It's super appreciated.

I'm unfamiliar with how moonrepo co-ordinates it's imports, but by your description, it sounds like there's an inherent mis-match.

The tsconfig points me to believe that the path aliasing that's been set up is being resolved to an absolute path (100% intentional), where as through tsc, that path import hasn't been.

For now, since it would appear that you have the module installed as a dependency from the workspace

(I'm assuming that there is still a node_modules folder in the same directory as the package.json)

, have you tried removing the path-aliasing from the tsconfig file and seeing if it builds correctly?

[sawa-ko]

Yes, removing the configuration of routes and route references works fine, but the problem is that I need that configuration for typescript typing because then it will complain that it does not find the types of that package. That's why I ask if there is a way to disable this behavior by setting a flag or something, to make it optional.

[lexedwards]

I need that configuration for typescript typing because then it will complain that it does not find the types of that package.

If that's the case, I would look into how @naeko/services is set up, and if it's creating a d.ts file for typescript to consume. It sounds as if the configuration with paths is aiding typescript in this module, because @naeko/services isn't doing it itself.

However, if you can do me a favour, if you are able to produce a minimal reproduction of the issue in a repo and share that, I can better investigate the issue and see what behaviour is needed to better support this use case.

[sawa-ko]

The problem is because of the types property of the package.json file of the @naeko/services project, and it does not have a single types file to be able to reference it that way, since it is not bundled, that is why typescript shows type errors if you do not do what moonrepo does in the tsconfig.json file automatically.

The @naeko/services project is not bundled because it has code that loads classes based on directories, and so on.

TypeScript (tsc) generates a structure like this one from @naeko/service.

- dist
	- main.js
	- main.d.ts
	- services
		- service.js
		- service.d.ts
- package.json
- CHANGELOG.md

So there is no single type file that has everything. I hope you find this information useful as I am unable to provide you with a repository for its reproduction at this time.

[lexedwards]

Directory structures like these are no problem - You might be interested in the reasoning behind the "exports" field in package.json - it's been a talking point from the creators @ Redux Toolkit and they faced a similar issued when it came to consuming the library that they ship.

TL;DR - "exports" property in package.json is a powerhouse for this "multiple modules in a single library" approach, examplified here: https://github.com/reduxjs/redux-toolkit/blob/556b20b1f75ef214a34876385626659c5e9b7f57/packages/toolkit/package.json#L28-L50

[sawa-ko]

Yes, I understand your point, but it is a very cumbersome thing to do when you have many modules that you need to export.