ts-loader does not work with @types (with latest versions)

Created on 2 Jan 2018  路  14Comments  路  Source: TypeStrong/ts-loader

Expected Behaviour

@types (particularly jasmine) should be compiled correctly by ts-loader

Actual Behaviour

errors are produced by ts-loader:

ERROR in ./test/index.spec.ts
(4,1): error TS2304: Cannot find name 'describe'.

ERROR in ./test/index.spec.ts
(7,5): error TS2304: Cannot find name 'beforeEach'.

ERROR in ./test/index.spec.ts
(11,5): error TS2304: Cannot find name 'it'.

ERROR in ./test/index.spec.ts
(12,9): error TS2304: Cannot find name 'expect'.

Steps to Reproduce the Problem

clone this repo:
https://github.com/SierraNL/webpack-typescript-jasmine (not mine)
use @types instead of typings
(sample package.json will be posted as a comment)

Location of a Minimal Repository that Demonstrates the Issue.

sorry, can't do this as I have no git access to github from work

I have found similar issues to this but mostly they were using old versions of ts-loader or typescript. This is using ts-loader 2.0.1 and typescript 2.6.1.
In my example tsc builds fine but ts-loader does not.

I hope that this is a config issue but I have spent some time researching this and can't fix it.

All 14 comments

package.json:

{
  "name": "webpack.typescript.jasmine",
  "version": "1.0.0",
  "description": "Webpack, TypeScript & Jasmine",
  "main": "dev-build.js",
  "author": "Leon Grave",
  "license": "MIT",
  "scripts": {
    "test": "karma start",
    "build-tsc": "tsc",
    "build-webpack": "webpack"
  },
  "devDependencies": {
    "@types/jasmine": "^2.8.2",
    "jasmine-core": "^2.5.2",
    "karma": "^1.5.0",
    "karma-chrome-launcher": "^2.0.0",
    "karma-jasmine": "^1.1.0",
    "karma-webpack": "^2.0.2",
    "node-sass": "^4.5.0",
    "sass-loader": "^6.0.2",
    "style-loader": "^0.13.2",
    "ts-loader": "^2.0.1",
    "typescript": "^2.2.1",
    "webpack": "^2.2.1",
    "webpack-dev-middleware": "^1.10.1"
  }
}

I have just realised that I am not using the latest release of ts-loader at all - but importantly I am using version 2. Another issues that I found had a similar issue that was in version 1 but fixed in version 2.

unfortunately on my the private npm repo at work I only have access to 2.0.1 :-(

is this supposed to work in 2.0.1?
I am expecting that the answer is just going to be to be to upgrade to the latest version - but the last package I requested took 6 weeks :'(

Honestly I can't remember. But I don't see those issues with 3.2. I recommend downloading 3.2 and testing it even if you can't use it immediately. I'm sorry for your workplace pain!

I think I have the same problem. Inside vscode the typescript intellisense plugin finds the import just fine but webpack with ts-loader fails.

./package.json

  "devDependencies": {
    "@types/snapsvg": "^0.4.30",
    "ts-loader": "^3.2.0",
    "webpack": "^3.10.0"

./src/index.ts

import * as Snap from 'snapsvg'

The file ./node_modules/@types/snapsvg/index.d.ts exists and looks just fine (as well as its dependency @types/mina).

./webpack.config.js

module.exports = {
    entry: './src/index.ts',
    devtool: 'inline-source-map',
    resolve: {
        extensions: [ '.tsx', '.ts', '.js' ],
    },
    output: {
        filename: 'js/bundle.js',
        path: path.resolve(__dirname, 'dist')
    },
    module: {
        rules: [
            {
                test: /\.tsx?$/,
                use: 'ts-loader',
                exclude: /node_modules/,
            }
        ]
    },

(I tried with or without the exclude, just in case. No luck)

webpack says:

ERROR in ./src/index.ts
Module not found: Error: Can't resolve 'snapsvg' in '<<myfolder>>\src'

I don't have any 'types' or 'typeRoots' options in tsconfig.json or in the ts-loader options of webpack.config.js, although I have tried to add them just in case, with no luck.

@TheJare could you provide a minimal repro please. I can only imagine this is some kind of config issue. @types usage is kinda fundamental!

Sure, here's a minimal repro. As far as I can see the config is minimal but should work. In the project I ran into this the tsconfig and webpack.config were more elaborate but not terribly so.

repro704.zip

Sorry could you put that on github so I can see the code? I'm on my phone I'm afraid

Sure https://github.com/TheJare/temp_tsl704

Relevant error running webpack:

ERROR in ./src/index.ts
Module not found: Error: Can't resolve 'snapsvg' in 'D:\Dev\ts\temp\repro704\src'

Complete output of webpack --verbose:

npm run build

> [email protected] build D:\Dev\ts\temp\repro704
> webpack --verbose

Hash: 35789d710dd0c3e287d6
Version: webpack 3.10.0
Time: 1034ms
       Asset     Size  Chunks             Chunk Names
js/bundle.js  2.77 kB       0  [emitted]  main
Entrypoint main = js/bundle.js
chunk    {0} js/bundle.js (main) 143 bytes [entry] [rendered]
    > main [0] ./src/index.ts
    [0] ./src/index.ts 143 bytes {0} [depth 0] [built]

ERROR in ./src/index.ts
Module not found: Error: Can't resolve 'snapsvg' in 'D:\Dev\ts\temp\repro704\src'
resolve 'snapsvg' in 'D:\Dev\ts\temp\repro704\src'
  Parsed request is a module
  using description file: D:\Dev\ts\temp\repro704\package.json (relative path: ./src)
    Field 'browser' doesn't contain a valid alias configuration
  after using description file: D:\Dev\ts\temp\repro704\package.json (relative path: ./src)
    resolve as module
      D:\Dev\ts\temp\repro704\src\node_modules doesn't exist or is not a directory
      D:\Dev\ts\temp\node_modules doesn't exist or is not a directory
      D:\Dev\ts\node_modules doesn't exist or is not a directory
      D:\Dev\node_modules doesn't exist or is not a directory
      D:\node_modules doesn't exist or is not a directory
      looking for modules in D:\Dev\ts\temp\repro704\node_modules
        using description file: D:\Dev\ts\temp\repro704\package.json (relative path: ./node_modules)
          Field 'browser' doesn't contain a valid alias configuration
        after using description file: D:\Dev\ts\temp\repro704\package.json (relative path: ./node_modules)
          using description file: D:\Dev\ts\temp\repro704\package.json (relative path: ./node_modules/snapsvg)
            no extension
              Field 'browser' doesn't contain a valid alias configuration
              D:\Dev\ts\temp\repro704\node_modules\snapsvg doesn't exist
            .tsx
              Field 'browser' doesn't contain a valid alias configuration
              D:\Dev\ts\temp\repro704\node_modules\snapsvg.tsx doesn't exist
            .ts
              Field 'browser' doesn't contain a valid alias configuration
              D:\Dev\ts\temp\repro704\node_modules\snapsvg.ts doesn't exist
            .js
              Field 'browser' doesn't contain a valid alias configuration
              D:\Dev\ts\temp\repro704\node_modules\snapsvg.js doesn't exist
            as directory
              D:\Dev\ts\temp\repro704\node_modules\snapsvg doesn't exist
[D:\Dev\ts\temp\repro704\src\node_modules]
[D:\Dev\ts\temp\node_modules]
[D:\Dev\ts\node_modules]
[D:\Dev\node_modules]
[D:\node_modules]
[D:\Dev\ts\temp\repro704\node_modules\snapsvg]
[D:\Dev\ts\temp\repro704\node_modules\snapsvg.tsx]
[D:\Dev\ts\temp\repro704\node_modules\snapsvg.ts]
[D:\Dev\ts\temp\repro704\node_modules\snapsvg.js]
[D:\Dev\ts\temp\repro704\node_modules\snapsvg]
 @ ./src/index.ts 3:11-29
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! [email protected] build: `webpack --verbose`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Gamera\AppData\Roaming\npm-cache\_logs\2018-01-27T23_02_00_020Z-debug.log

Hey @TheJare,

The problem was you hadn't setup snapsvg as a dependency of your project. See my fix below:

john@john-dev:/mnt/c/source/temp_tsl704$ yarn add snapsvg
yarn add v1.3.2
[1/4] Resolving packages...
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 2 new dependencies.
鈹溾攢 [email protected]
鈹斺攢 [email protected]
Done in 53.68s.
john@john-dev:/mnt/c/source/temp_tsl704$ yarn build
yarn run v1.3.2
$ webpack --verbose
Hash: b8f7df314d4d5719a898
Version: webpack 3.10.0
Time: 1689ms
       Asset    Size  Chunks                    Chunk Names
js/bundle.js  285 kB       0  [emitted]  [big]  main
Entrypoint main [big] = js/bundle.js
chunk    {0} js/bundle.js (main) 282 kB [entry] [rendered]
    > main [0] ./src/index.ts
    [0] ./src/index.ts 139 bytes {0} [depth 0] [built]
    [1] ./node_modules/snapsvg/dist/snap.svg.js 282 kB {0} [depth 1] [built]
        cjs require snapsvg [0] ./src/index.ts 3:11-29
Done in 2.61s.

It's worth saying that the @types/ definition packages do not have a dependency on the packages they type.

Thanks John. In my "real project" I am including the snapsvg library (the original js) myself in the html, not via npm. I was already doing that for other libraries that are not part of the @types ecosystem.

I guess I am confused. Which part of the webpack / ts-loader / @types / tsc system is asking for the actual package when I import the @types definitions? I have not been able to find a reference to this requirement in any of the documentations. Is there a way to suppress this behaviour so that the library/package is not bundled by webpack and only the @types are used to compile the client typescript correctly? ts-loader docs describe it as a "drop in tsc replacement", but of course tsc does not look for the package, only the types.

TIA

@johnnyreilly I have the same problem with node which I can not add as a dependency ;-)
but it does compile just shoing the error and also I can not make webpack dev server to work

Hey @TheJare

I think this is covered by webpack's externals functionality - check it out!

Works perfectly! Thank you so much for your help, and sorry for sidetracking you!

I can confirm that my issue is sorted when updating to 3.2.0 (and yes, it has taken this long to get that version available for use...)

Was this page helpful?
0 / 5 - 0 ratings