Includes baseUrl in parsed path when it shouldn't

[spentak]

Great work on this well needed package!

I think there may be an issue with resolving paths. With the correct setup for paths I get an error.

So I have:

Project
    src
    dist

My tsconfig:

        "outDir": "dist",
        "baseUrl": "./",
        "paths": {
            "api/*": ["src/api/*"],
            "utilities/*": ["src/utilities/*"],
            "middleware/*": ["src/middleware/*"],
            "resolvers/*": ["src/resolvers/*"],
            "graphql-schemas/*": ["src/graphql-schemas/*"]
        },

The line of code:

import { graphqlSchema } from 'graphql-schemas/schemas';

Trace:

Error: Cannot find module '../src/graphql-schemas/schemas'

Expected parsed path: ../graphql-schemas/schemas

The paths that the parser are putting out are using the baseUrl as the root (it appears), but in reality they should be in relation to the directory in which they live? Like a reverse traverse upwards until they find the file?

And if i take the src out of the arrays, TypeScript wont' compile because it can't resolve it. Can't have one without the other :)

[spentak]

Possible solution would be to allow an argument to the CLI --jsPath

tspath -f --jsPath ./dist (instead of reading from tsconfig baseUrl)

[duffman]

HI there! I will reproduce your setup and look for possible solutions! brb :) thanks for helping me squash a potential bug!

[erikjalevik]

Unfortunately @spentak's solution doesn't work for me. I have:

"outDir": "dist",
"baseUrl": "./src"

and after building the project, I run:

./node_modules/.bin/tspath -f -jsPath ./dist

TSPath then tries to find the dist folder under src:

Error: ENOENT: no such file or directory, scandir: 'D:\...\projectName\src\dist'

It should be looking in 'D:...\projectName\dist'.

EDIT: only after writing this do I notice that your solution is only a SUGGESTED solution. Doh.

[ShepelievD]

@erikjalevik the same

[erikjalevik]

I also put up a SO question here:

https://stackoverflow.com/questions/50101147/how-to-configure-electron-to-use-typescripts-baseurl

But still no replies.

[ShepelievD]

@erikjalevik I have a decision, but my webstorm breaks, will answer you once success

[ShepelievD]

@erikjalevik what I did:

my tsconfig.json

{
  "compilerOptions": {
    "module": "commonjs",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "esModuleInterop": true,
    "target": "esnext",
    "noImplicitAny": true,
    "moduleResolution": "node",
    "sourceMap": true,
    "outDir": "dist",
    "baseUrl": ".",
    "paths": {
      "@config/*": ["src/config/*"],
      "@models/*": ["src/models/*"],
      "@routes/*": ["src/routes/*"],
      "@src/types/*": ["src/types/*"],
      "@utils/*": ["src/utils/*"],
      "@graphql/*": ["src/graphql/*"],
      "*": [
        "node_modules/*"
      ]
    }
  },
  "include": [
    "src/**/*"
  ]
}

I made tsconfig.path.json

{
  "compilerOptions": {
    "outDir": "dist",
    "baseUrl": ".",
    "paths": {
      "@config/*": ["config/*"],
      "@models/*": ["models/*"],
      "@routes/*": ["routes/*"],
      "@src/types/*": ["types/*"],
      "@utils/*": ["utils/*"],
      "@graphql/*": ["graphql/*"],
      "*": ["node_modules/*"]
    }
  }
}

what I have to do is change TS_CONFIG to my custom own, ideally, we have to pass option to config file. But still it looks not quite good, I guess for first time we have to do it.

@duffman what do you think?

[ShepelievD]

@erikjalevik https://github.com/ShepelievD/tspath check it, example usage tspath -f ./dist -c tsconfig.path.json

Yeah, I know that is tricky, but I need it urgent :)

[dnt294]

@ShepelievD 404 not found :(

[ShepelievD]

@kaanoo2904 yes, removed it, because decided to use https://github.com/ilearnio/module-alias

package.json:

{
  ...
  "_moduleAliases": {
    "@config": "dist/config",
    "@models": "dist/models",
    "@routes": "dist/routes",
    "@types": "dist/types",
    "@utils": "dist/utils",
    "@graphql": "dist/graphql"
  },
  ...
}

tsconfig.json:

{
  "compilerOptions": {
    "module": "commonjs",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "esModuleInterop": true,
    "target": "esnext",
    "noImplicitAny": true,
    "moduleResolution": "node",
    "sourceMap": true,
    "outDir": "dist",
    "baseUrl": "src",
    "paths": {
      "@config/*": ["config/*"],
      "@models/*": ["models/*"],
      "@routes/*": ["routes/*"],
      "@types/*": ["types/*"],
      "@utils/*": ["utils/*"],
      "@graphql/*": ["graphql/*"]
    }
  },
  "include": ["src/**/*"]
}

[iSuslov]

so.. it is useless because of this

[duffman]

so.. it is useless because of this

No, you are pretty useless at reading and interpreting stuff I´d say... not even tspath can help you there

[duffman]

This has been resolved in 1.3.5

Regarding the suggestion of having tspath accept a param specifying the dist folder, I really don´t see when you´d use that? Being able to make it independent of the tsconfig.json would perhaps be something you could use in a headless build process, I don´t know but to single out the dist directory makes no real sense?

[0x80]

@duffman I'm a little confused. I am experiencing the same issue as the OP using version 1.3.7. And if this has been resolved why is this issue still open?

My compiler options contain:

{
    "outDir": "build",
    "baseUrl": ".",
    "paths": {
      "@src/*": ["src/*"],
      "@modules/*": ["src/modules/*"],
      "@utils/*": ["src/utils/*"]
    },
	"include": ["src/**/*"]
}

Paths in the build directory are all one level off. They contain "src" when they shouldn't. What would be a fix for this?

[0x80]

For now I've worked around it using module-alias with the following in my package.json:

"_moduleAliases": {
    "@src": "build",
    "@modules": "build/modules",
    "@utils": "build/utils"
  },

My deployed code now runs (using google cloud functions). I'd still prefer to rewrite the paths with tspath though.

[nilswx]

The fact that this is still unresolved is completely bananas. 🍌

[duffman]

The fact that your structure becomes dist/src is because the source structure looks like that, that’s how the typescript compiler will output the result, and really how else do you expect it to work?? If you want to move around the result, create a gulpfile, shellscript or whatever, really don’t know what you expect tspath to do? Guess that src means source and move everything a level up, please explain or better yet push an updated version! mån 28 jan. 2019 kl. 12:58 skrev Nils Weldon <[email protected]>:

…

The fact that this is still unresolved is completely bananas. 🍌 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAy_9b6ifuw0153Tsn3V-EB7eLM_msuks5vHuXggaJpZM4Rg9V_> .

[nilswx]

For runtime resolution of src/... files to a build or dist directory, I can confirm that https://github.com/ilearnio/module-alias works beautifully. It also doesn't need a tsconfig.json at runtime. Make sure to programmatically register your @app (or whatever) module to __dirname, so that it ends up looking under your build directory when resolving your absolute paths.

If you prefer 'build time' rewriting with a compiler plugin, the only ttypescript plugin that I actually got to work in this src scenario was https://github.com/zerkalica/zerollup. It gets the job done and requires no runtime magic, but keep in mind that from now on you need to tell your IDE (VS Code / IntelliJ / ...) to compile with ttsc rather than tsc.

IntelliJ in particular is not a fan of this, and I'd randomly end up with a build directory that still had the @absolute import paths untouched, so I abandoned compile time rewriting in favor of runtime resolution with a module alias.

I hope this is of help to someone. 🙂

[nilswx]

@duffman: I was hoping that tspath would recognize the use of rootDir in tsconfig.json and strip it from the paths.

[0x80]

@duffman Sorry for not being clear. With the tsconfig I use, src will not be part of the paths in the build (or dist) output.

{
    "outDir": "build",
    "baseUrl": ".",
    "paths": {
      "@src/*": ["src/*"],
      "@modules/*": ["src/modules/*"],
      "@utils/*": ["src/utils/*"]
    },
	"include": ["src/**/*"]
}

A file at /src/modules/foo.ts will compile to /build/modules/foo.js and /src/bar.ts to /build/bar.js. If bar.ts was referencing foo.ts via path alias @modules/foo, the output of tspath will currently be ./src/modules/foo.js.

Alternatively I have tried this config:

{
    "outDir": "build",
    "baseUrl": "./src",
    "paths": {
      "@src/*": ["./*"],
      "@modules/*": ["modules/*"],
      "@utils/*": ["utils/*"]
    },
	"include": ["src/**/*"]
}

This effectively results in the same output file structure. If I then try to run tspath, I get an error because it tries to read from /build/src.

So it seems to me there is an incompatibility between tspath and tsc, in how the tsconfig is interpreted. It is not something I would like or know how to solve by running a shell script or adding a build tool like Gulp.

[acathur]

Hi guys, I have created a pull request to solve this problem. #27

[jdtzmn]

@duffman Can we get @acathur's PR merged? Are we waiting on something?

[JosephKrusling]

Since this is still unchanged, I recommend migrating to https://github.com/joonhocho/tscpaths

[duffman]

I Will Review the PR ons 1 apr. 2020 kl. 18:58 skrev Joseph Krusling <[email protected]>:

…

Since this is still unchanged, I recommend migrating to https://github.com/joonhocho/tscpaths — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAADF75VAUKQ57U72AEFPTDRKNXCNANCNFSM4EMD2V7Q> .