-
Notifications
You must be signed in to change notification settings - Fork 148
Compatibility with typings
#173
Comments
The workaround that worked for me was specifying in my tsconfig.json: "typeRoots": [
"typings/global",
"typings/modules"
] It will make TS2 prefer |
The whole pattern of adding the global node declaration as a dependency (not peerDependency) is the cause of this issue. See this build for example: https://travis-ci.org/felixfbecker/merkel/builds/166880677 This is really not only for compatibility with typings. |
@felixfbecker You might be interested in #107. |
This issue seems to have reared its head again here --> aws/aws-sdk-js#1223. Messed my day up pretty bad. The fix above did work for me though |
Use only the type definitions from typings since we have a conflict between global typings definitions from mocha and node @types definition from jasmine, that comes with protractor, similar to microsoft/types-publisher#173. Alternatively we could switch to jasmine completly but that's a different story.
I'm closing this issue since it is no longer relevant. Most of the libraries have switched to |
Hi,
I encountered an error yesterday when trying to consume a library using
@types
in my main project usingtypings
(see details). I expected that the way my dependencies handle their definitions would not break my build (that there was some "isolation" between the definitions used internally by my dependencies and my own project).The problem is a conflict between
@types/node
used by the dependency andenv~node
(fromtypings
) used by my main project. I published a minimal repo demonstrating the issue.lib-a
has annpm
dependency on@types/node
main-project
has annpm
dependency onlib-a
main-project
has atypings
dependency onenv~node
Trying to run
tsc
inmain-project
results in the following error:My question is: how do I use
@types
in my library without breaking the builds of the dependant projects usingtypings
ortsd
?I assume that this issue is caused by the flat structure used by
npm@3
, but even so I don't feel that it's right that a dependency can pollute my global namespace. If in the future a second dependencylib-b
that uses@types/node@7
(incompatible with the definitions for Node 6), will I have conflicts between my two dependencies ? (I think that npm will take care of the scope, but I prefer to ask).How should Node's types be installed, as
dependencies
ordevDependencies
? This might be related to #81, except that the definitions for Node seem to affect the whole environment: I'd prefer to be the one to install it (at the top level) and not have it dictated by dependencies. Installing it asdevDependencies
would solve the compatibility issue (since it is no longer installed for the consumer package) but I'm not sure if it is the intended way.What is the solution to handle the transition ? (#4 is a blocker for me but I'd still would like to be able to consume dependencies that use
@types
).The text was updated successfully, but these errors were encountered: