-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publishing to NPM while using the tsconfig paths? #25677
Comments
This is not a support forum. Questions should be asked at StackOverflow or on Gitter.im. Cross posting from StackOverflow is also not a good idea. |
@kitsonk as you can see in the question I did first ask on SO. There are also other people that have asked. One of the reasons I have asked it is I wonder if it's essentially a bug? In other words we can do what articles like this say that we can do. But once we go to publish to NPM, we effectively have to undo it all and go back to relative paths. So in other words since Typescript compiles the path that the typescript compiler and ts-node know how to interpret via Also asked a follow up question on SO just now here. Thoughts? |
TypeScript is a means of typing JavaScript code -- but the types just describe existing behaviors, they don't change them. The declarations in |
That's one aspect of it. I would say the biggest driver and rationale for Typescript is to make Javascript as easy to refactor as say Java within an Eclipse IDE, and if this aspect of it remains as is we are going to see a lot of confusion moving forward. Typescript could easily support a configuration flag for generating relative paths for NPM published modules that way we could code in pretty non relative paths, yet have the ES5 generated code be usable in Node. It seemed so obvious to me that that was what the |
You waited only a few hours before opening an issue. That is what I meant by cross posting. Instead of waiting for an answer on StackOverflow.
This conflicts with TypeScript non-goals:
I don't think it is a good idea to build large code bases without testing before you realised you did not correctly understand the option. The documentation for the option makes it pretty clear it is designed to allow mimicking of the behaviour of loaders like Require.js or System.js, not rewriting module IDs. |
True but there were already other similar questions that had gone unanswered for months, so I figured I'd just try again to reaffirm what I already suspected was true.
Typescript already compiles to various Javascript module formats. I, and I'm sure others, were totally expecting the paths to be converted when compiling to the ES5/CommonJS format. Ts-node does this in memory.
Precisely. With the current state of things the only way to use the All this does is force everyone that wants to use the At least have the Typescript compiler warn that the |
Right now devs are looking for the development features that the Say Goodbye to ‘../../../..’ in your TypeScript Imports describes. Because we all like easy to read and refactor imports. Node does require relative paths in order to resolve modules, but Typescript appears to have solved this. Awesome. This is why we love Typescript. It's worth the learning curve investment because it has awesome features like this. The article goes on to say:
Yes that would be really great. If we can use absolute paths that are easy to refactor what's not to love about that? The article gives a demo and goes on to say:
SWEET! But guess what, the most common scenario for using and publishing your Javascript once the project is complete is not supported. I'm pretty sure Typescript will get a lot more frustrated user comments around this down the line. |
So it appears that there is a solution module-alias which has 10,000 weekly downloads. So 10,000 devs are having to perform additional weekly to configure something that should be part of the compilation process. However it does not appear that this works with NPM packages that are built to support other TS projects (*.d.ts and corresponding *.js files), so it's back to the drawing board. If we are compiling to CommonJS / ES5 format there is essentially one target runtime, Node. So we expect the compiled code to resolve properly in that runtime. |
I think this could be this simple.
And now we have a set of *.d.ts files and *.js files that can be npm installed if we go to So if |
I've implemented a script that converts all of my projects absolute paths to relative paths. After having done this it seems even more obvious to me that this is the right thing to do when compiling to ES5 / CommonJS format. Honestly what could the down side possibly be? |
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed. |
Until officially supported, I've created a solution that replaces absolute paths back to relative paths that does not require any dependencies nor babel. It also fixes .d.ts files (currently only if they are in the same directory as output. declarationDir support can be added too. PRs are welcomed!). |
I made a transform for this, checkout https://github.com/LeDDGroup/typescript-transform-paths |
I think this issue was dismissed exceedingly unfairly; this is a very valid issue that me and many others are experiencing given the popularity of the Is there any possibility that this issue can be re-considered? |
This issue seems simple: When you use the "paths" feature of the TypeScript compiler, it produces invalid output. That seems like a significant defect. |
Hello guys, It's been a few days that I'm stuck on mapping my paths... I also believe like many others that there should be a better way of doing so. I am using webpack for this project and also have the webpack path aliases that map... Anyways, I believe that in a node project the main paths should be in the package.json. Then the tsconfig should configure accordingly (I mean use the package.json paths). Thus every output (build) from this project should have its paths replaced by the absolute ones. I spent too much time on this... It's sad to admit like many other that such a simple thing is not yet implemented. I'll have to find a workaround. Good luck to all of you ! |
@kitsonk This issue seems to have caused a lot of friction. I'll give my best go at countering your argument against it.
This feature request is not in conflict with non-goal 4 since publishing TypeScript code to npm is a basic build workflow, not a complex one. Non-goal 5 says we shouldn't emit different code than JavaScript just because a different TypeScript typing is there. Well, JavaScript emits code that is compatible with Node even with the use of import aliases. TypeScript is an existing offender to non-goal 5 by emitting incompatible code with the use of import aliases. In order to abide by non-goal 5, TypeScript needs to emit valid JavaScript code that is consumable by Node. And if there was any doubt about the validity of this issue, please re-read non-goals 1, 2, and 7 for further clarification.
Import aliases are used by most major IDE's and JavaScript frameworks. Was due consideration given to these import patterns? Just reading through it seems to have gotten brushed aside rather brashly. |
Kinda sad that at the end of 2022 we still have no official solution. I am trying to export my project's core code to library, where I extensibly use aliases, and what now? I need to do some postprocessing on my own because I trusted in the clean code? Come on. Honestly, when I first saw the path aliases I was delighted. Now I feel like after getting married </3 |
Hello - Hope it's OK that I ask this question here. I first posted it to SO and have seen similar questions asked without answers. This is the SO question:
https://stackoverflow.com/questions/51353762/compiling-typescript-path-aliases-to-relative-paths-for-npm-publishing
In addition I created a small project with a directory structure like this:
"use strict";
exports.__esModule = true;
var foo_1 = require("@fireflysemantics/foo/foo");
function boo() {
console.log("The boo is loose");
foo_1.foo();
}
exports.boo = boo;
The text was updated successfully, but these errors were encountered: