Skip to content
This repository was archived by the owner on Dec 1, 2019. It is now read-only.

Cannot find typings with typescript@beta and @type #196

Closed
sanex3339 opened this issue Jul 18, 2016 · 15 comments
Closed

Cannot find typings with typescript@beta and @type #196

sanex3339 opened this issue Jul 18, 2016 · 15 comments

Comments

@sanex3339
Copy link

This loader has same problem as ts-loader after typescript-2.0.0-beta update.

Possible solution by @mhegazy:

assuming that the missing API is getDirectories, then the result should be the list of directories under the given path, see default implementation in https://github.com/Microsoft/TypeScript/blob/767da71cc13422c65a6369e26c3a6cfe894a05ef/src/compiler/program.ts#L982

original issue DefinitelyTyped/DefinitelyTyped#10113

original problem:

After installing @types/node i got multiple errors:

(1,21): error TS2307: Cannot find module 'fs'.
(3,23): error TS2307: Cannot find module 'path'.
(80,41): error TS2304: Cannot find name 'process'.
(5,12): error TS2304: Cannot find name 'global'.
(6,5): error TS2304: Cannot find name 'require'.

I add all definitions to types

But as said https://github.com/mhegazy in DefinitelyTyped/DefinitelyTyped#10113 (comment)

you should not need to add the types property, the behavior should be the same with or without it

2.0.0-beta compiler.

project: https://github.com/sanex3339/javascript-obfuscator/tree/dev

project tsconfig:

{
  "compilerOptions": {
    "target": "ES6",
    "module": "commonjs",
    "sourceMap": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "removeComments": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "noUnusedLocals": true
  }
}

entry point

"use strict";

import { JavaScriptObfuscator } from './src/JavaScriptObfuscator';

if (!(<any>global)._babelPolyfill) {
    require('babel-polyfill');
}

module.exports = JavaScriptObfuscator;

to reproduce you must clone dev branch, and run node_modules/.bin/webpack --watch

@s-panferov
Copy link
Owner

@sanex3339 it seems that you're using ts-loader, not awesome-typescript-loader. But I make sure that your case compiles normally.

@s-panferov
Copy link
Owner

@sanex3339 your case compiles on OSX, so please describe your env.

@s-panferov
Copy link
Owner

@sanex3339 confirmed that it works on windows too

@jefbarn
Copy link

jefbarn commented Jul 25, 2016

I tried moving my project from using typings to @types from npm today, but found that niether ATL or ts-loader is picking up the @types files. My project compiles fine using typescript 2.0, but throws type errors when loading using webpack.

also tried loading the TsConfigPathsPlugin. Is there some setting I need to enable for this?

@filipesilva
Copy link

filipesilva commented Jul 26, 2016

Also using [email protected] and trying to user @types, with limited success.

I have installed @types/jasmine and have the following TS code:

D:\sandbox\webpack-project\src\app\app.component.ts

// ...
describe('test', () => {
  it('should test', () => {
    expect(true).toBeTruthy();
  });
});

My tsconfig.json at D:\sandbox\webpack-project\src\

{
  "compilerOptions": {
    "declaration": false,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "lib": ["es6", "dom"],
    "mapRoot": "./",
    "module": "es6",
    "moduleResolution": "node",
    "outDir": "../dist/out-tsc",
    "sourceMap": true,
    "target": "es5",
    "typeRoots": [
      "../node_modules/@types"
    ]
  }
}

I get these errors:

ERROR in [default] D:\sandbox\webpack-project\src\app\app.component.ts:12:0
Cannot find name 'describe'.

ERROR in [default] D:\sandbox\webpack-project\src\app\app.component.ts:13:2
Cannot find name 'it'.

ERROR in [default] D:\sandbox\webpack-project\src\app\app.component.ts:14:10
Cannot find name 'expect'.

If I explicitly add the ref, it works fine /// <reference path="../../node_modules/@types/jasmine/index.d.ts" />.

This leads me to believe it's a problem with loading @types via Typescript.

@filipesilva
Copy link

I experimented a bit more and found that explicitly using the types array in tsconfig fixes it, but it shouldn't be necessary:

    "types": [
      "jasmine"
    ]

@jefbarn
Copy link

jefbarn commented Jul 26, 2016

Yeah, I found the same...adding to 'types' fixes AWL errors but I agree it shouldn't be necessary.

@s-panferov s-panferov reopened this Jul 26, 2016
@s-panferov
Copy link
Owner

@filipesilva, @jefbarn why do you think it should not be necessary?

@sanex3339
Copy link
Author

yes, becouse @mhegazy said so:

you should not need to add the types property, the behavior should be the same with or without it. so looks like a loader issue to me. this is a new feature in TS 2.0, so it is possible that the loader is not returning the expect result to the API.

@s-panferov
Copy link
Owner

Ah, I see, it's supposed that directories fromtypeRoots should be included automatically. I'll investigate this in #203

@filipesilva
Copy link

@s-panferov I expected ATL to follow the same behavior as tsc, and under my scenario tsc was able to find the typings using only typeRoots without the types array.

@jefbarn
Copy link

jefbarn commented Jul 26, 2016

Additionally, tsc 2.0 will also search @types folder in node_modules without adding anything to typeRoots. I couldn't find this documented anywhere, but you can see it if you use --traceResolution with tsc.

@sanex3339
Copy link
Author

ping

@JMStudiosJoe
Copy link

It might also help to note that not only do you need to install with npm @types/express but you also need to do it with npm express for the .js files. I assumed the first command would also take care of .js being able to recognize the express framework through @types but now I know you must also install with npm install express --save.

@filipesilva
Copy link

Have tested with [email protected] (which includes #203) and can verify typeRoots works properly without having a types array.

Great job @s-panferov!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants