SERIOUS BUG: signalr-client breaks when used with angular-cli #729

williamBurgeson · 2017-08-16T14:27:06Z

When creating a vanilla angular-cli project and adding signalr-client (currently alpha1 26666) the app crashes when trying to reference any members exposed from the import statement.

This occurs at the point the members are actually referenced: the act of including the members in the code file doesn't trigger the error - I'm assuming that is because of lazy loading the resources when they are actually used, but that's of course outside my area.

This occurs both in dev and prod builds. In my case it originally broke in a angular-cli based .net core project, however I was easily able to reproduce the same outcome in a vanilla angular-cli project.
Note I am using yarn, however that shouldn't make any difference

To reproduce the issue, I did the following:

Create a new angular-cli project ng new test-signalr-client
[I saved the initial commit in the auto-created git repo]
I added the signalr-client - to do this in yarn I followed the following steps :-
a. yarn config get registry (so I can revert back afterwards)
b. yarn config set registry https://dotnet.myget.org/f/aspnetcore-ci-dev/npm/
c. yarn add signalr-client
d. yarn config set registry https://registry.yarnpkg.com (to revert back to standard yarn registry)
[Saved commit]
Amended the app.component.cs as follows:-


import { TransferMode } from 'signalr-client';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent implements OnInit {
  title = 'app works!';

  ngOnInit() {
    var x = TransferMode.Binary;
  }
}

ng serve or ```ng serve --prod``
Open dev tools in the browser, and view the console errors.

Although this is an alpha build, it goes without saying that there's no point even trying to integrate this new "style" of signalr into a .net core/angular-cli project until this is resolved

The text was updated successfully, but these errors were encountered:

Tragetaschen · 2017-08-16T19:10:53Z

I've just tried most of what you describe in my it's-just-angular app:

Install signalr-client via npm (as described in the README.md)
Add a constructor to my app.component.ts (ts , not cs) doing console.log(TransferMode.Binary);
Run webpack (I'm not using the angular CLI)
Watch the Browser Console in Edge and see a lone 2 as output

It would help if you could post the actual error message

williamBurgeson · 2017-08-16T19:36:19Z

Hi, thanks for looking at this. Our project uses angular-cli, so we don't really have the option of going back and only using webpack.

I used Google Chrome on Mac, however the problem (and error messages) was the same with the main project which is on Windows.

The error message which is shown in the console is

    at webpackMissingModule (index.js:3)
    at Object.defineProperty.value (index.js:3)
    at Object.<anonymous> (index.js:9)
    at __webpack_require__ (bootstrap 7bbd9d4ed3b402ba8388:52)
    at Object.128 (app-routing.module.ts:15)
    at __webpack_require__ (bootstrap 7bbd9d4ed3b402ba8388:52)
    at Object.129 (app.component.ts:10)
    at __webpack_require__ (bootstrap 7bbd9d4ed3b402ba8388:52)
    at Object.118 (src async:7)
    at __webpack_require__ (bootstrap 7bbd9d4ed3b402ba8388:52)

This is index.js within the package itself

There are also 9 warnings from various files:

./~/signalr-client/dist/src/index.js
3:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

This includes: index.js, HttpConnection.js, HttpClient.js, HubConnection.js, Transports.js, HttpError.js, Observable.js, Formatters.js and JsonHubProtocol.js (all of which are in the dist folder of course). These warnings also occur in the command line (Terminal on mac, PS on Windows)

The fact I used yarn shouldn't have any effect - it just loaded alpha1-26666 from the dotnet.myget feed, so it is the same.

If I run ng serve--prod, the error I got was slightly different:

ERROR in ./src/main.ts
Module not found: Error: Can't resolve './$$_gendir/app/app.module.ngfactory' in '/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/src'
 @ ./src/main.ts 4:0-74
 @ multi webpack-dev-server/client?http://localhost:4200 ./src/main.ts
webpack: Failed to compile.

This error occurs on the command line, in the browser console, and angular-cli is kind enough to actually display it in the browser itself with a nice dramatic black background.

Tragetaschen · 2017-08-16T19:39:41Z

That last error is angular/angular-cli#7113 and has nothing to do with the browser error

williamBurgeson · 2017-08-16T20:05:19Z

The debug message will probably be more helpful; I just included prod for completeness.

Obviously the software is still in alpha, but assuming that an angular-cli front end environment were to be supported I would expect it to just work.

I suspect that it's not playing nicely with the default webpack configuration in angular-cli - I know it's possible to "eject" the webpack to be able to edit it, but again I would not have expected to have to do that for a single 3rd party dependency.

In fact, assuming you are able to reproduce this, I suspect you will need to eject in order to work out what differences there may be in the default webpack config which fails, with your webpack setup (which works, as you say)

Tragetaschen · 2017-08-16T20:24:31Z

If you search for the warning messages, everything points to webpack (which the angular CLI uses internally). Also a missing module suggests you have an inconsistent module state in the browser (have you been running with HMR?).

I highly doubt this is an issue in signalr-client. The generated js code and the accompanying .d.ts files all look perfectly fine and also work in my angular (4.3.1) + webpack (3.3.0) build.

I strongly suggest against ejecting from the angular-cli. I once saw John Papa on stage doing this and then making fun of the hundreds and hundreds of lines of webpack configuration code.

If your experience hasn't told that yet: When you come from the wonderful, stable and polished world of .NET with thoroughly tested libraries and fast tooling that makes you smile all the time, then web development is a dark world of continuous pain. Here are two examples:

If you read the above bug carefully (and the webpack bug), then you'll realize that the angular-cli team chose to manipulate the internal state of a referenced library. When that dependency changed its inner workings, angular-cli broke on machines that newly npm installed. It also didn't help that they blindly inclued newer versions...
Google internally doesn't use angular-cli, they have their own, internal build system based on the closure compiler

I suggest you ask the angular-cli team what they are doing to break using signalr-client. In a simpler webpack setup than theirs, it just works.

williamBurgeson · 2017-08-16T21:09:59Z

Could you confirm:

Do you plan to support angular-cli?
If not, is there a sample application I could use to work out how I need to set things up? The only example I could find online was https://codingblast.com/asp-net-core-signalr-simple-chat/ and in that tutorial he was pulling out the js file and copying it to his wwwroot folder, which doesn't seem very nice.

One of the key advantages with angular-cli is precisely because you don't need to worry about webpack configuration or anything else. Everything just works, and the onus is usually on the component developer to make it work.

I do recognise this is early stage stuff, but as things stand it doesn't seem to work with angular-cli which if not resolved would make it difficult to use signal r in many angular projects.

Tragetaschen · 2017-08-16T21:43:57Z

@moozzyk
After further testing: webpack doesn't like the generated UMD js files in the dist/src folder.
When you just import the TransferMode const (!) enum and use the Binary value, then TS erases the import and replaces the reference with the 2 literal in the generated js file. That means webpack doesn't see any of the actual signalr-client code and generates a working setup.

Once you start importing and using real code like HttpConnection, webpack shows the above warning and doesn't include the signalr-client "modules" (the UMD js files in dist/src). This results in errors like the above or in my case Cannot find module "." in the browser.

I'm by no means an expert on how js libraries should ship (there are waaaay too many options on both ends), but I just did a little experiment:
With the client's tsconfig.json containing

[...]
"module": "es2015",
"target": "es5",
"lib": ["es6", "dom"],
"moduleResolution": "node",
[...]

I rebuilt the .js and the .d.ts files and placed them them into the node_modules/signalr-client/dist/src folder of my actual project. These files result in a successful webpack build (and the expected failing HTTP request against my server when starting a HttpConnection). Running gulp with that config fails, though, for browserify-msgpackprotocol:

SyntaxError: 'import' and 'export' may only appear at the top level (2:0) while parsing [...]\Sign
alR\client-ts\dist\src\MessagePackHubProtocol.js while parsing file: [...]\\SignalR\client-ts\dist\
src\MessagePackHubProtocol.js

This is usually when my head starts hurting...

moozzyk · 2017-08-16T22:00:46Z

@Tragetaschen - does it work if you remove const on this line:

SignalR/client-ts/Microsoft.AspNetCore.SignalR.Client.TS/Transports.ts

Line 11 in 4898c0d

export const enum TransferMode {

?

Tragetaschen · 2017-08-17T09:47:35Z

Huh? The const doesn't break anything. It's just responsible for why the initial reproduction didn't fail:

TypeScript sees the import
TypeScript replaces the const enum with its literal value during transpilation and removes the enum type from the import
TypeScript removes the (now empty) import / Webpack ignores the empty import
Webpack sees the transpiled js without any references to signalr-client and succeeds

williamBurgeson · 2017-08-17T10:08:09Z

FYI, I tried replacing the enum ref with a reference to a class, which generates more warnings in the terminal (the browser was the same)

    //console.log(TransferMode.Binary);
    var http = new HttpClient();

It probably has little effect, but it might be worth pointing out that the package.json generated by ng-cli refers to @angular/cli version 1.0.0; whereas the most recent version is 1.3.0, where they've ironed out a few issues. The errors I got were the same, but that might help you if you upgrade that within the project too.

The warnings were as below:

Williams-MacBook-Pro-2:test-signalr-client williamburgeson$ ng serve
** NG Live Development Server is listening on localhost:4200, open your browser on http://localhost:4200 **
Date: 2017-08-17T10:01:31.487Z                                                          
Hash: 5f0e33af0a41be1c3451
Time: 7663ms
chunk {inline} inline.bundle.js, inline.bundle.js.map (inline) 5.83 kB [entry] [rendered]
chunk {main} main.bundle.js, main.bundle.js.map (main) 9.9 kB {vendor} [initial] [rendered]
chunk {polyfills} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 204 kB {inline} [initial] [rendered]
chunk {styles} styles.bundle.js, styles.bundle.js.map (styles) 11.3 kB {inline} [initial] [rendered]
chunk {vendor} vendor.bundle.js, vendor.bundle.js.map (vendor) 2.93 MB [initial] [rendered]

WARNING in ./node_modules/signalr-client/dist/src/index.js
3:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
    at CommonJsRequireContextDependency.getWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/dependencies/CommonJsRequireContextDependency.js:27:4)
    at Compilation.reportDependencyErrorsAndWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:677:24)
    at Compilation.finish (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:535:9)
    at applyPluginsParallel.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compiler.js:512:17)
    at /Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/tapable/lib/Tapable.js:289:11
    at _addModuleChain (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:481:11)
    at processModuleDependencies.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:452:13)
    at _combinedTickCallback (internal/process/next_tick.js:95:7)
    at process._tickCallback (internal/process/next_tick.js:161:9)

WARNING in ./node_modules/signalr-client/dist/src/HttpClient.js
3:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
    at CommonJsRequireContextDependency.getWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/dependencies/CommonJsRequireContextDependency.js:27:4)
    at Compilation.reportDependencyErrorsAndWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:677:24)
    at Compilation.finish (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:535:9)
    at applyPluginsParallel.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compiler.js:512:17)
    at /Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/tapable/lib/Tapable.js:289:11
    at _addModuleChain (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:481:11)
    at processModuleDependencies.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:452:13)
    at _combinedTickCallback (internal/process/next_tick.js:95:7)
    at process._tickCallback (internal/process/next_tick.js:161:9)

WARNING in ./node_modules/signalr-client/dist/src/HttpConnection.js
11:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
    at CommonJsRequireContextDependency.getWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/dependencies/CommonJsRequireContextDependency.js:27:4)
    at Compilation.reportDependencyErrorsAndWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:677:24)
    at Compilation.finish (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:535:9)
    at applyPluginsParallel.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compiler.js:512:17)
    at /Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/tapable/lib/Tapable.js:289:11
    at _addModuleChain (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:481:11)
    at processModuleDependencies.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:452:13)
    at _combinedTickCallback (internal/process/next_tick.js:95:7)
    at process._tickCallback (internal/process/next_tick.js:161:9)

WARNING in ./node_modules/signalr-client/dist/src/HubConnection.js
11:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
    at CommonJsRequireContextDependency.getWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/dependencies/CommonJsRequireContextDependency.js:27:4)
    at Compilation.reportDependencyErrorsAndWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:677:24)
    at Compilation.finish (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:535:9)
    at applyPluginsParallel.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compiler.js:512:17)
    at /Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/tapable/lib/Tapable.js:289:11
    at _addModuleChain (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:481:11)
    at processModuleDependencies.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:452:13)
    at _combinedTickCallback (internal/process/next_tick.js:95:7)
    at process._tickCallback (internal/process/next_tick.js:161:9)

WARNING in ./node_modules/signalr-client/dist/src/Transports.js
11:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
    at CommonJsRequireContextDependency.getWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/dependencies/CommonJsRequireContextDependency.js:27:4)
    at Compilation.reportDependencyErrorsAndWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:677:24)
    at Compilation.finish (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:535:9)
    at applyPluginsParallel.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compiler.js:512:17)
    at /Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/tapable/lib/Tapable.js:289:11
    at _addModuleChain (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:481:11)
    at processModuleDependencies.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:452:13)
    at _combinedTickCallback (internal/process/next_tick.js:95:7)
    at process._tickCallback (internal/process/next_tick.js:161:9)

WARNING in ./node_modules/signalr-client/dist/src/HttpError.js
3:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
    at CommonJsRequireContextDependency.getWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/dependencies/CommonJsRequireContextDependency.js:27:4)
    at Compilation.reportDependencyErrorsAndWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:677:24)
    at Compilation.finish (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:535:9)
    at applyPluginsParallel.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compiler.js:512:17)
    at /Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/tapable/lib/Tapable.js:289:11
    at _addModuleChain (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:481:11)
    at processModuleDependencies.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:452:13)
    at _combinedTickCallback (internal/process/next_tick.js:95:7)
    at process._tickCallback (internal/process/next_tick.js:161:9)

WARNING in ./node_modules/signalr-client/dist/src/Observable.js
3:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
    at CommonJsRequireContextDependency.getWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/dependencies/CommonJsRequireContextDependency.js:27:4)
    at Compilation.reportDependencyErrorsAndWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:677:24)
    at Compilation.finish (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:535:9)
    at applyPluginsParallel.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compiler.js:512:17)
    at /Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/tapable/lib/Tapable.js:289:11
    at _addModuleChain (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:481:11)
    at processModuleDependencies.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:452:13)
    at _combinedTickCallback (internal/process/next_tick.js:95:7)
    at process._tickCallback (internal/process/next_tick.js:161:9)

WARNING in ./node_modules/signalr-client/dist/src/Formatters.js
3:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
    at CommonJsRequireContextDependency.getWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/dependencies/CommonJsRequireContextDependency.js:27:4)
    at Compilation.reportDependencyErrorsAndWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:677:24)
    at Compilation.finish (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:535:9)
    at applyPluginsParallel.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compiler.js:512:17)
    at /Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/tapable/lib/Tapable.js:289:11
    at _addModuleChain (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:481:11)
    at processModuleDependencies.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:452:13)
    at _combinedTickCallback (internal/process/next_tick.js:95:7)
    at process._tickCallback (internal/process/next_tick.js:161:9)

WARNING in ./node_modules/signalr-client/dist/src/JsonHubProtocol.js
3:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
    at CommonJsRequireContextDependency.getWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/dependencies/CommonJsRequireContextDependency.js:27:4)
    at Compilation.reportDependencyErrorsAndWarnings (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:677:24)
    at Compilation.finish (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:535:9)
    at applyPluginsParallel.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compiler.js:512:17)
    at /Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/tapable/lib/Tapable.js:289:11
    at _addModuleChain (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:481:11)
    at processModuleDependencies.err (/Users/williamburgeson/Documents/DevWork/Experimental/test-signalr-client/test-signalr-client/node_modules/webpack/lib/Compilation.js:452:13)
    at _combinedTickCallback (internal/process/next_tick.js:95:7)
    at process._tickCallback (internal/process/next_tick.js:161:9)

webpack: Compiled with warnings.

Tragetaschen · 2017-08-17T11:00:37Z

I've created a small reproduction: https://gist.github.com/Tragetaschen/cbff57f27c82d19fa017d753f23b3c43

Put these two files in the client-ts folder.
have the ./dist/src available
npm install webpack
node_modules\.bin\webpack (this shows the warnings)
node ./output.js (this shows the error)

When you use "module": "es2015" in the tsconfig, webpack doesn't show warnings and running output.js shows no errors.

williamBurgeson · 2017-08-17T12:34:26Z

@Tragetaschen is this entry for internal use or for me to try? Are you suggesting I download the signal r repo from github? In principle, not a problem, however can you confirm if so which branch should I download?

On a basic level, from our project's point of view we need to simply be able to reference the signalr-client in an angular-cli project (vanilla or otherwise) and have it not error out. You should see the problem if you install angular-cli and follow the steps I did (obviously don't worry about yarn, that's just a detail).

Tragetaschen · 2017-08-17T13:14:48Z

@williamBurgeson I've removed angular-cli from the picture and reduced the problem to Webpack failing to handle UMD modules produced by TypeScript. When TypeScript produces es2015 modules, Webpack is happy, but then browserify fails.

The only thing I can suggest for you and your project: don't use nightly builds if want things to just work. I'm trying to give the SignalR team a simple reproduction for the mentioned problem. As I've said: the module and bundling landscape in JavaScript is very complex and building a npm package that works in many (all?) environments is a challenge many projects face.

I, personally, would like signalr-client package to just work in a Webpack build (and by extension hopefully in angular-cli).

williamBurgeson · 2017-08-17T13:29:55Z

Thanks for looking at this. As I said previously I accept that it is an early alpha build, so it will not be perfect.

As for use cases, I imagine it would need to work in all major framework environments, however for us the only game in town is angular-cli, which, I suspect, although fairly new, is going to be become the default and most popular way of scaffolding angular applications in the coming months and years.

Marcelh1983 · 2017-08-17T20:45:51Z

I got it working with angular-cli and works fine in development. Only error I get when building is:

ERROR in vendor.aa3432c7091a7afeab7f.bundle.js from UglifyJs
Unexpected token: name (Base64EncodedHubProtocol) [vendor.aa3432c7091a7afeab7f.bundle.js:34178,10]

williamBurgeson · 2017-08-17T21:04:40Z

@Marcelh1983 does it work with both ng serve and ng serve --prod? For most potential errors, I would expect ng build and ng build --prod would produce the same errors, were they to occur

Marcelh1983 · 2017-08-18T05:29:15Z

@williamBurgeson ng serve --prod also fails. without --prod it runs fine.

it probably has to do with the way I import types.
I now reference like this:
import { HubConnection, HttpConnection, TransportType, IHttpClient } from 'signalr-client/dist/browser/signalr-client.js';
and I get the Unexpected token: name (Base64EncodedHubProtocol) error.

When I import like this:

import { HubConnection, HttpConnection, TransportType, IHttpClient } from 'signalr-client';

I get a lot of warnings first:

WARNING in ./node_modules/signalr-client/dist/src/index.js
3:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted......

And eventually:

ERROR in vendor.c7bbaffc8012e19b81ad.bundle.js from UglifyJs
Unexpected token: name (HubConnection) [vendor.c7bbaffc8012e19b81ad.bundle.js:21458,10]

williamBurgeson · 2017-08-18T07:52:58Z

@Marcelh1983 thanks for the progress. You'll probably be aware but in general I think the protocol is that you import types from the top level of a 3rd party dependency, rather than deep-linking. rxjs is an exception to this of course...

moozzyk · 2017-08-21T18:52:38Z

@williamBurgeson - I think I have a fix that fixes webpack errors when using ng serve. ng serve --prod won't work out of the box due to UglifyJs not supporting ES6.

@Marcelh1983 - I could reproduce this error:

ERROR in vendor.c7bbaffc8012e19b81ad.bundle.js from UglifyJs
Unexpected token: name (HubConnection) [vendor.c7bbaffc8012e19b81ad.bundle.js:21458,10]

It seems it is because UglifyJs does not support ES6

moozzyk · 2017-08-21T22:26:12Z

The fix is in 0.1.0-alpha1-26727 or newer. The UglifyJs issue is external.

williamBurgeson · 2017-08-22T09:58:21Z

I have downloaded version 26733

I uncommented the import statement at the top of the file and included the following code in my service (which is just for starters obviously):-

    let transportType = TransportType.WebSockets;
    let http = new HttpConnection(`http://${document.location.host}/hubs/scores`, { transport: transportType });
    let connection = new HubConnection(http);
    connection.start();

I ran ng build and there were no errors, and when I hit play on the actual VS project and the code appears to have hit this with the following console log message:

WebSocket connected to ws://localhost:56311/hubs/scores?id=143b080e-d125-4681-ba54-a047cb6bbc60

which is from Transports.js line 27

At least at first glance this seems to be working, so I move on from here.

When I tried running ng build --prod I got the same uglify.js error as above so that would need to be fixed also as soon as possible, however as things stand I am no longer blocked on signalr for development at least.

I will update if I encounter any further related issues in the dev build

williamBurgeson · 2017-08-23T04:53:40Z

Have we got ng build --prod working?

If not I will open another issue. There's also one or two other things I will look at and possibly raise.

moozzyk · 2017-08-23T06:16:26Z

@williamBurgeson - As explained above ng build --prod is an external issue. angular-cli seems to be using UglifyJS which does not support ES6. The signalr client as it is will not compile to ES5.

Marcelh1983 · 2017-08-24T08:30:10Z

This is what I did to be able to use this package in production:

ng eject --prod --aot
npm i [email protected] -D
change location of UglifyJSPlugin in webpack.config const UglifyJSPlugin = require('uglifyjs-webpack-plugin');
changed parameter for UglifyJSPlugin:

new UglifyJSPlugin({
      parallel: {
        cache: true,
        workers: 2
      }
    })

Seems to work

williamBurgeson · 2017-08-25T07:18:59Z

@Marcelh1983 thanks for this, obviously ejecting is something I'd prefer to avoid, however if changes are needed within the build environment for it to work then I suppose I could raise an enhancement with the angular-cli project to allow certain things to be more flexible. I'll also talk to my managers about finding the time to understand exactly what other external projects do to ensure they are able to ork with angular-cli with no problem.

williamBurgeson · 2017-08-29T09:58:06Z

I have raised this with the angular-cli team: angular/angular-cli#7532

williamBurgeson · 2017-09-04T16:58:06Z

See the latest update, they are considering enhancing uglify to support es6: angular/angular-cli#7532 (comment)

Although this isn't under the signalR team's control, until they fix this we can't really deem signalr-client to be angular-cli production ready

williamBurgeson · 2017-10-02T10:04:24Z

Belatedly, I can confirm that the fix proposed in angular/angular-cli#7610 works - I currently have @angular/cli 1.5.0-beta.2 in my environment (I'm not sure if 1.4.4 will work)

sniffer327 · 2017-11-02T15:21:47Z

Angular-cli has updated 1.5.0. It's solved this problem.

Current version of @aspnet/signalr-client: '1.0.0-alpha2-final' in my project.
Now i'm using import { HubConnection } from '@aspnet/signalr-client' without errors while production building.

Angular-cli releases link: https://github.com/angular/angular-cli/releases

moozzyk self-assigned this Aug 16, 2017

moozzyk closed this as completed Aug 22, 2017

moozzyk mentioned this issue Aug 25, 2017

Angular 4 / SignalR angular-cli production build fails #765

Closed

williamBurgeson mentioned this issue Aug 29, 2017

Probable issue with uglify, causing signalr-client to fail to build in production angular/angular-cli#7532

Closed

davidfowl mentioned this issue Sep 13, 2017

UglifyJs compile exception with @aspnet/signalr-client #867

Closed

moozzyk mentioned this issue Sep 27, 2017

SignalR in embedded web browser control #953

Closed

whut mentioned this issue Oct 4, 2017

SignalR npm package should point to ES5 script version #983

Closed

moozzyk mentioned this issue Nov 18, 2017

@aspnet/signalr-client dont work with angular cli when run build prod mode #1136

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SERIOUS BUG: signalr-client breaks when used with angular-cli #729

SERIOUS BUG: signalr-client breaks when used with angular-cli #729

williamBurgeson commented Aug 16, 2017

Tragetaschen commented Aug 16, 2017

williamBurgeson commented Aug 16, 2017

Tragetaschen commented Aug 16, 2017 •

edited

Loading

williamBurgeson commented Aug 16, 2017 •

edited

Loading

Tragetaschen commented Aug 16, 2017

williamBurgeson commented Aug 16, 2017

Tragetaschen commented Aug 16, 2017

moozzyk commented Aug 16, 2017 •

edited

Loading

Tragetaschen commented Aug 17, 2017

williamBurgeson commented Aug 17, 2017 •

edited

Loading

Tragetaschen commented Aug 17, 2017

williamBurgeson commented Aug 17, 2017

Tragetaschen commented Aug 17, 2017

williamBurgeson commented Aug 17, 2017

Marcelh1983 commented Aug 17, 2017

williamBurgeson commented Aug 17, 2017

Marcelh1983 commented Aug 18, 2017 •

edited

Loading

williamBurgeson commented Aug 18, 2017

moozzyk commented Aug 21, 2017

moozzyk commented Aug 21, 2017

williamBurgeson commented Aug 22, 2017 •

edited

Loading

williamBurgeson commented Aug 23, 2017

moozzyk commented Aug 23, 2017

Marcelh1983 commented Aug 24, 2017

williamBurgeson commented Aug 25, 2017

williamBurgeson commented Aug 29, 2017

williamBurgeson commented Sep 4, 2017

williamBurgeson commented Oct 2, 2017

sniffer327 commented Nov 2, 2017

SERIOUS BUG: signalr-client breaks when used with angular-cli #729

SERIOUS BUG: signalr-client breaks when used with angular-cli #729

Comments

williamBurgeson commented Aug 16, 2017

Tragetaschen commented Aug 16, 2017

williamBurgeson commented Aug 16, 2017

Tragetaschen commented Aug 16, 2017 • edited Loading

williamBurgeson commented Aug 16, 2017 • edited Loading

Tragetaschen commented Aug 16, 2017

williamBurgeson commented Aug 16, 2017

Tragetaschen commented Aug 16, 2017

moozzyk commented Aug 16, 2017 • edited Loading

Tragetaschen commented Aug 17, 2017

williamBurgeson commented Aug 17, 2017 • edited Loading

Tragetaschen commented Aug 17, 2017

williamBurgeson commented Aug 17, 2017

Tragetaschen commented Aug 17, 2017

williamBurgeson commented Aug 17, 2017

Marcelh1983 commented Aug 17, 2017

williamBurgeson commented Aug 17, 2017

Marcelh1983 commented Aug 18, 2017 • edited Loading

williamBurgeson commented Aug 18, 2017

moozzyk commented Aug 21, 2017

moozzyk commented Aug 21, 2017

williamBurgeson commented Aug 22, 2017 • edited Loading

williamBurgeson commented Aug 23, 2017

moozzyk commented Aug 23, 2017

Marcelh1983 commented Aug 24, 2017

williamBurgeson commented Aug 25, 2017

williamBurgeson commented Aug 29, 2017

williamBurgeson commented Sep 4, 2017

williamBurgeson commented Oct 2, 2017

sniffer327 commented Nov 2, 2017

Tragetaschen commented Aug 16, 2017 •

edited

Loading

williamBurgeson commented Aug 16, 2017 •

edited

Loading

moozzyk commented Aug 16, 2017 •

edited

Loading

williamBurgeson commented Aug 17, 2017 •

edited

Loading

Marcelh1983 commented Aug 18, 2017 •

edited

Loading

williamBurgeson commented Aug 22, 2017 •

edited

Loading