Skip to content
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

TypeScript compiler option "moduleResolution" is not inferred as it is by tsc #132

Closed
chbrown opened this issue Jan 6, 2016 · 6 comments
Labels

Comments

@chbrown
Copy link

chbrown commented Jan 6, 2016

tsc will infer that moduleResolution: "node" if I have module: "commonjs" in my tsconfig.json, even if I also have target: "ES6" (it won't default to node-style moduleResolution if module is set to "es6" and target is also set to "ES6").

However, when compiling with ts-loader via webpack, I have to explicitly add moduleResolution: "node" to my tsconfig file to avoid "Cannot find module 'whatever'" errors in the output.

Adding that line, "moduleResolution": "node" is trivial. Figuring out that I need to add it, to resolve errors that webpack + ts-loader was throwing at me, was frustrating. I would expect ts-loader's (default) behavior to match tsc's (default) behavior, particularly when the ts-loader log message says it's using exactly the same tsconfig file that tsc is using.

@chbrown
Copy link
Author

chbrown commented Jan 6, 2016

The versions I'm using, FWIW:

├── [email protected]
├── [email protected]
├── ...
├── [email protected]
├── [email protected]
└── [email protected]

@jbrantly
Copy link
Member

jbrantly commented Jan 8, 2016

The goal is definitely for ts-loader to work the same as tsc. Do you have a simple file structure/example that you could provide which shows the issue? What does your import look like and where does the module reside?

@chbrown
Copy link
Author

chbrown commented Jan 8, 2016

Not the simplest example, but here's what I was working on when I encountered this. And the steps to recreate (I just tested this like 5 minutes ago so if you don't hit the same issue then something weird is going on with my machine):

git clone https://github.com/chbrown/unicode-ui.git
cd unicode-ui
npm install                                              # sorry, lots of dependencies
node_modules/.bin/tsc                                    # works
node_modules/.bin/webpack --config webpack.config.js     # works
# edit tsconfig.json, remove this line: "moduleResolution": "node",
node_modules/.bin/tsc                                    # works
node_modules/.bin/webpack --config webpack.config.js     # doesn't work

webpack output with error:

ts-loader: Using [email protected] and /tmp/unicode-ui/tsconfig.json
Hash: d7efaf08b7986c362606
Version: webpack 1.12.10
Time: 5961ms
     Asset     Size  Chunks             Chunk Names
 bundle.js     1 MB       0  [emitted]  app
unidata.js  2.35 MB       1  [emitted]  unidata
   [0] multi unidata 28 bytes {1} [built]
    + 223 hidden modules

ERROR in ./app.tsx
(10,58): error TS2307: Cannot find module 'unidata'.

unidata is another package of mine, installed via npm, pretty simple, but bulky — it just reformats the Unicode 8.0 character data into plain old JavaScript objects, and exposes them via an index.js file using the index.d.ts type definitions that are automatically recognized with TypeScript >= 1.6's handy "node"-style module resolution algorithm.

The import line in question in app.tsx is a run-of-the-mill ES6-style import:

import {Block, getBlocks, Character, getCharacters} from 'unidata';

@jbrantly
Copy link
Member

jbrantly commented Jan 8, 2016

Perfect, thanks!

@jbrantly
Copy link
Member

I believe this is related to #111. Basically TypeScript's logic is if module: "commonjs", then moduleResolution: "node" is inferred (see here). However, ts-loader currently does some magic where if target: "ES6" is set then module: "commonjs" is ignored and module: "none" is used instead. This used to be desirable because otherwise TypeScript would throw an error. However, that is no longer the case, so I believe once #111 is fixed this will be as well.

@jbrantly
Copy link
Member

This has been fixed and published in v0.8.0.

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

No branches or pull requests

2 participants