Skip to content

Typescript ignores typings when using tsconfig.json paths #17583

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

Closed
WoMayr opened this issue Aug 3, 2017 · 3 comments
Closed

Typescript ignores typings when using tsconfig.json paths #17583

WoMayr opened this issue Aug 3, 2017 · 3 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@WoMayr
Copy link

WoMayr commented Aug 3, 2017

TypeScript Version: 2.3.4, 2.4.2, 2.5.0-dev.20170801

fabric@1.7.17 and @types/fabric are installed.

Code

tsconfig.json

{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "baseUrl": "src/",
        "sourceMap": true,
        "outDir": "dist/out-tsc",
        "paths": {
            "fabric": [ "../node_modules/fabric/dist/fabric.require.js" ]
        }
    },
    "exclude": [
        "node_modules"
    ],
    "compileOnSave": false
}

src/app.ts

import * as fabric from "fabric";

window.addEventListener("load", function () {
    const canvas = new fabric.Canvas("my-canvas");

    // create a rectangle object
    var rect = new fabric.Rect({
        left: 100,
        top: 100,
        fill: "red",
        width: 20,
        height: 20,
        lockUniScaling: true
    });

    // "add" rectangle onto canvas
    canvas.add(rect);

    // canvas.toSVG() is faulty inside definitions
    console.log(canvas.toSVG());
});

Expected behavior:
TSC should report an error that toSVG needs parameters.

Actual behavior:
typescript doesn't load any type definitions for the fabric module.

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Aug 3, 2017

If you have .d.ts files available, why are you re-mapping to the .js file which has no type information associated with it? That's why it's not working the way you expect.

In fact, why are you even using paths if you have the @types package available? When targeting commonjs (or using nodejs for your moduleResolution strategy) the .d.ts files should automatically get picked up.

@DanielRosenwasser DanielRosenwasser added the Working as Intended The behavior described is the intended behavior; this is not a bug label Aug 3, 2017
@WoMayr
Copy link
Author

WoMayr commented Aug 3, 2017

I do understand. The problem is, that I am using it in the context of an angular4 project using angular-cli. Angular-CLI does not support aliasing or at least only using the information from paths (See angular/angular-cli#6282).

But to use fabric.js with import I need to use a different file than the one stated in the package.jsons main field or the typings from @types/fabric won't fit. My hope was that with paths I can target the correct JavaScript file and I expected it to leave the connection to the typings intact as it was even suggested from the angular-cli team.

I somehow thought that it might be a bug with tsc but thinking at it again: paths only tells tsc where to look for the typings at it does not alter the imports itself. So no wonder it doesn't work as I expected it.

Is there a way to use paths and still have the type information available or at least attach it manually? I tried adding ../node_modules/@types/fabric to the fabric entry in paths but that didn't work (desperate attempt).

@mhegazy
Copy link
Contributor

mhegazy commented Aug 17, 2017

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@mhegazy mhegazy closed this as completed Aug 17, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

3 participants