Duplicate identifier

[ssougnez]

Hi,

First of all, I'd like to say that this post is not a duplicate of this one. I read it and it does not really apply.

I'm currently using TypeScript 2.0.3 to be able to use "@types" and I'm creating an Angular2 app. Actually, everything was fine with the app, then I tried to use ckeditor. So I installed it via NPM and I noticed that "CKEDITOR" was not know in my ts files. So I installed "@types/ckeditor" to make it available.

I'm also using webpack to bundle my whole application and since the moment I downloaded the typings for "ckeditor", I have a bunch of:

Duplicate identifier 'text'.
Duplicate identifier 'cssStyle'.
...

Note that I don't think that it comes from the typings themselves as I also have the exact same issue with "js-base64". At first, I thought that they were the culprit but now that I also have this behaviour with "ckeditor", I'm starting to doubt...

Regarding webpack, I have nothing fancy. The only thing worth showing is:

entry: {
    'polyfills': './src/polyfills.ts',
    'vendor': './src/vendor.ts',
    'app': './src/main.ts'
}

And here is what the "vendor.ts" file contains:

import '@angular/platform-browser';
import '@angular/platform-browser-dynamic';
import '@angular/core';
import '@angular/common';
import 'rxjs';
import 'ckeditor';
import 'ckeditor/lang/en';

Note that the bundle is correctly generated and the site works (well almost but that's my fault ^^), but I'm flooded by the "duplicate identifier" errors and I could miss other errors. I'm currently using webpack 1.13.2 and webpack-dev-server 1.16.1 but I tried with webpack 2 and I have the same issue.

Besides, I also exclude "node_modules" from my "tsconfig.json".

One last thing: I don't do any reference to "@types/ckeditor/index.d.ts" anywhere in my project and I don't think angular2 is doing it either, so I don't understand how the references inside could be duplicated.

Thanks

[mhegazy]

@ssougnez can you share a minimal repro i can look at.

One last thing: I don't do any reference to "@types/ckeditor/index.d.ts" anywhere in my project and I don't think angular2 is doing it either, so I don't understand how the references inside could be duplicated.

Please note that all files in node_modules\@types are included in your project. if you do not want to include them set "types":[] in your tsconfig.json under "compilerOptions". See http://www.typescriptlang.org/docs/handbook/tsconfig-json.html#types-typeroots-and-types for more details.

[ssougnez]

By "minimal repo", you mean a small github project to reproduce the issue ? (Sorry I'm quite new to all of this :-$)

Please note that all files in node_modules@types are included in your project. if you do not want to include them set "types":[] in your tsconfig.json under "compilerOptions". See http://www.typescriptlang.org/docs/handbook/tsconfig-json.html#types-typeroots-and-types for more details.

I just tried that, it solves the issue of duplicates but of course, now, I have a lot of other errors like "Cannot find XXX".

[RyanCavanaugh]

We would prefer literally the fewest number of files and lines of code possible that it takes to reproduce the problem

[ssougnez]

Ok, I'll work something out tomorrow, now, I'm going to bed :p Thanks

[jasonswearingen]

@ssougnez fyi there are a lot of problems with tsc colliding with dupe-identifiers from any/all *.d.ts files found under node_modules.

This becomes especially apparent when you use npm link inside your app to link a custom-library you are working on, as the linked module's node_modules are then crawled, in addition to your custom-library dependencies that have already been installed in your app already (when you did npm install custom-library)

Thus, basically doing local development of npm modules is crippled. Here are some issues tracking this problem, and module resolution in general: #10364 #9552 #10649 #9091

From those issues, it looks like TS 2.1 is the release they are looking to resolve these issues. Lets hope so! I've been waiting a long time to do proper typescript development of npm modules!!!

[jugglingcats]

Not sure if it will help, but I was getting a lot of duplicate definition errors using Mocha and Chai in my project using tsconfig.json with @types installed. Not using any vendor.json.

I took a clue from the comment about adding types: [] to the compilerOptions. I added this and got different errors about chai, describe etc not being defined, so I set the following:

    "types": [
      "@types/chai",
      "@types/mocha"
    ]

And hey presto Webpack and Karma run without any errors. Hopefully it will help someone else.

[donaldpipowitch]

I have a lot of issues with Duplicate identifiers while development (using symlinks, compile deps of deps and stuff like that). It would be great if somethings could be solved in the future.

[jasonswearingen]

on windows, here is a workaround using a batch script with robocopy. I wrote this because the tsconfig.json based work arounds don't fix visualstudio unfortunately, as it seems to have another means of scanning solution ts files which breaks due to the same/similar issue.

:rerunloop
    @echo watching for changes to project files..............  (Ctrl-C to cancel)

    @rem *******************************
    @rem npm link fix :  copy code into node_modules of the consuming project:  xlib --> blib and slib
    @robocopy ..\xlib\src ..\blib\node_modules\xlib\src *.*  /MIR /NJH /NJS /NDL /XD .git
    @if NOT "%errorlevel%" == "0" (
        @rem copy occured, so copy both

        @robocopy ..\xlib\dist ..\blib\node_modules\xlib\dist *.*  /MIR /NJH /NJS /NDL /XD .git 
        @robocopy ..\xlib\src ..\slib\node_modules\xlib\src *.*  /MIR /NJH /NJS /NDL /XD .git       
        @robocopy ..\xlib\dist ..\slib\node_modules\xlib\dist *.*  /MIR /NJH /NJS /NDL /XD .git

        @rem  set the src dirs readonly
        @attrib +R ..\blib\node_modules\xlib\src\*  /S /D
        @attrib +R ..\slib\node_modules\xlib\src\*  /S /D
    )
    @rem *******************************
    @rem another alternative way to fix npm link issues:  copy source code to the consuming project and have the consuming project treat it as a native part of it's project
    @robocopy .\dtll-interop\src\mirror-source .\dtll-app-browser\src\dtll-interop *.*  /MIR /NJH /NJS /NDL
    @if NOT "%errorlevel%" == "0" (
        @rem copy occured, so copy both
        @robocopy .\dtll-interop\src\mirror-source .\dtll-server-dashboard\src\dtll-interop *.* /MIR /NJH /NJS /NDL
        @rem and set reseults readonly
        @attrib +R .\dtll-server-dashboard\src\dtll-interop\*  /S /D
        @attrib +R .\dtll-app-browser\src\dtll-interop\*  /S /D
    )   
    @timeout /t 1 /nobreak > NUL
@goto rerunloop

[dbettini]

Happened to me with CKEDITOR as well. That one maybe has a problem with its type declarations. However, having a library that pollutes the global scope, like jquery, creates a big problem, even if using separate instances of tsc.

In my setup, I'm using webpack to bundle two different client apps, 'studio-client' and 'learn-client'. Both are typescript angular apps, but I wanted to keep types and tsconfig in each of them, instead of my main server app (that is responsible for bundling and serving them). I'm using lerna to link my packages, so all three are in the same /packages directory, but client packages are symlinked to node_modules of the server:

• server
  • node_modules
    • studio-client
    • learn-client

So I used this webpack configuration for typescript files:

const tsClientNames = ["studio", "learn"];
tsClientNames.forEach(name => webpackConfig.module.rules.push({
    test: /\.tsx?$/,
    include: path.join(require.resolve(`${name}-client`), ".."),
    use: [
        {
            loader: "awesome-typescript-loader",
            query: {
                instance: name,
                configFileName: path.join(require.resolve(`${name}-client`),"../tsconfig.json")
            }
        },
        "angular-router-loader",
        "angular2-template-loader"
    ]
}));

Basically, I'm creating 2 named typescript instances, 'learn' and 'studio', giving the path to tsconfig for each one (which makes it look into correct types). I even scoped webpack loaders only to each specific client using 'include' option.

Everything works!
... on the first run.

So I run webpack dev server, and everything actually compiles without errors. And then I edit a file. If I'm lucky, nothing happens. If I do it a few more times (although sometimes once is enough), different kinds of errors can occur.

ERROR in [learn] ../learn-client/node_modules/@types/jquery/index.d.ts:3776:5
    TS2300: Duplicate identifier 'export='.

ERROR in [learn] ../studio-client/node_modules/@types/jquery/index.d.ts:745:5
    TS2374: Duplicate string index signature.

ERROR in [learn] ../studio-client/node_modules/@types/jquery/index.d.ts:3347:5
    TS2374: Duplicate string index signature.

ERROR in [learn] ../studio-client/node_modules/@types/jquery/index.d.ts:3348:5
    TS2375: Duplicate number index signature.

ERROR in [learn] ../studio-client/node_modules/@types/jquery/index.d.ts:3776:5
    TS2300: Duplicate identifier 'export='.

Two tsc instances somehow intermingle. 'learn' instance is looking into both 'studio-client' and 'learn-client' types, and getting duplicates, although each instance of the loader was explicitly scoped to its own client. 'studio' is using jquery by importing it in the code, while 'learn' isn't, but it is using bootstrap which does, so it's still imported in the end.

ERROR in [learn] ../studio-client/components/editor/ckeditor.ts:30:23
    TS2304: Cannot find name 'CKEDITOR'.

This time, 'learn' instance is looking into 'studio-client' code, and deciding it needs ckeditor typings, although it shouldn't. @types/ckeditor exists only in studio-client, so learn-client does not have it. So, unlike before, 'learn' was seeing both instances of @types/jquery, it now does not see the one from 'studio', which makes it throw errors.

So in the first case, errors were happening because of one instance seeing types of the other as well. In the second case, errors were thrown because one instance was parsing the code of another without seeing its types.

Take notice that the build ALWAYS succeeds on the first run of the dev server, and when using webpack cli to create the bundle. So the only possibilities that I can think of here is:

• multiple tsc instances somehow sharing memory... Not sure how webpack handles multiple instances of the same loader
• wrong instance is chosen for recompiling when live reload is occurring

Using typescript@2.2.1, webpack@2.2.1, webpack-dev-server@2.3.0.

Not sure if this is an issue with tsc, awesome-typescript-loader, or webpack...