Closed otbe closed 7 years ago
I think I got it. If I add
basePath = normalizeSlashes(basePath);
to the beginning of this function it works. Problem is that API users (like ts-loader) pass in a windows path, e.g. C:\Users\boo\dwatch
when used on windows, but TypeScript works with normalized
ones (slashes instead of backslashes). I guess parseJsonConfigFileContent
and any other API method should ensure this (by throwing or normalizing) or you should add it to the docs.
If fix is okay I will place a PR.
Thanks! :)
PRs welcomed.
Hi,
Im facing a problem with TypeScript@next (1.9.0-dev.20160612-1.0). Im using
ts-loader
alongside webpack to build my current project. This project is backed by travis and appveyor for OS X, linux and windows builds, but windows builds are broken since upgrading to TypeScript@next.The output of this function will result in different file lists on windows and for example OS X when using the
exclude
option.OS X output (correct):
Windows output (contains excluded paths):
It seems that this function fails to recognize the excluded file paths for windows. The
exclude
input parameter on windows is:(note the slashes compared to the file list above)
This behavior results in many
Duplicate Identifier
and other errors while compiling TS files. See https://ci.appveyor.com/project/otbe/dwatch/build/0.4.72 for example.When using
tsc
from the command line this does not happen. It seems to be related to the nodejs API of TypeScript. Related to #9049.Thanks!