Issue with @types/socket.io with electronize build

[hhfranzo]

Hi,

I'm experiencing an issue when I try to build the application with "electronize build /target win"
The build fails with the following message:

"Packaging app for platform win32 x64 using electron v3.0.0
Failed to locate module "@types/socket.io" from "."
This normally means that either you have deleted this package already somehow (check your ignore settings if using electron-packager). Or your module installation failed."

Did I miss to install some packages? Note that I already ran "npm install socket.io -g".

Thanks.

[hhfranzo]

Forgot to say that I'm using Electron.NET 0.0.10...

[JimmyTheJ]

I have been working on this repo for the last couple days as I have had a similar problem since upgrading to Dotnet Core 2.2.

You can fork the repo and change the BuildCommand.cs file for the CLI to do npm install without the --production and that might fix it. I plan on putting in a pull request with some fixes since 0.0.10 release and Dotnet Core 2.2 broke some things at some point soon but not sure exactly when.

[paillave]

Here is what is get at the end of the command electronize build /target win

C:\Users\paill\Documents\GitHub\Etl.Net\src\Paillave.Etl.Debugger>
Skip npm install, because node_modules directory exists in: C:\Users\paill\Documents\GitHub\Etl.Net\src\Paillave.Etl.Debugger\obj\desktop\win\node_modules
Build Electron Desktop Application...
Executing electron magic in this directory: C:\Users\paill\Documents\GitHub\Etl.Net\src\Paillave.Etl.Debugger\bin\desktop
Package Electron App for Platform win32...
Microsoft Windows [Version 10.0.17134.472]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\Users\paill\Documents\GitHub\Etl.Net\src\Paillave.Etl.Debugger\obj\desktop\win>electron-packager . --platform=win32 --arch=x64  --out="C:\Users\paill\Documents\GitHub\Etl.Net\src\Paillave.Etl.Debugger\bin\desktop" --overwrite
Packaging app for platform win32 x64 using electron v3.0.0
Failed to locate module "@types/socket.io" from "."
        This normally means that either you have deleted this package already somehow (check your ignore settings if using electron-packager).  Or your module installation failed.
C:\Users\paill\Documents\GitHub\Etl.Net\src\Paillave.Etl.Debugger\obj\desktop\win>
... done

What is strange is that the electronize start command works with no problem.

[paillave]

I found the reason of the bug (it actually seems to be a bug in ElectronNET).

On a fresh project (or at least, a where the folder obj/desktop/XXX doesn't exist already), the build with ElectronNET version 0.0.10 can't possibly work.

Here is the content of package.json that will be used to build electron host (the one in the folder obj\desktop\win):

Electron.NET/ElectronNET.Host/package.json

Lines 11 to 21 in dc3eec3

	"dependencies": {
	"detect-port": "^1.2.3",
	"electron": "^3.0.0",
	"socket.io": "^2.1.1"
	},
	"devDependencies": {
	"@types/socket.io": "^1.4.38",
	"@types/node": "^10.11.0",
	"tslint": "^5.11.0",
	"typescript": "^3.0.3"
	}

The problem is that the automatic batch executes an npm install --production like we can see in log and also in the source code of ElectronNET:

Electron.NET/ElectronNET.CLI/Commands/BuildCommand.cs

Line 94 in dc3eec3

ProcessHelper.CmdExecute("npm install --production", tempPath);

The problem is that --production argument for npm install asks npm to ignore what is mentioned in the devDependencies node. That is why electron is lost when trying to make the final build of the application as socket.io types are missing for typescript compilation.

This --production argument has been add by @GregorBiswanger for a big refactoring in the commit 524e6c8.
I could push a fix, but I can imagine he had a good reason to add this problematic switch as he is involved in this project since the start. It's better he chooses the proper solution for this issue.

[JimmyTheJ]

Yeah I ran into this problem too among others recently, so I just forked the repo and fixed it myself for the purposes of the project I'm working on. You can build the CLI .dll and just run a local version of it instead of the globally installed tool.

[paillave]

@JimmyTheJ Just saw that you actually mentioned it on a previous post. I didn't understand what you were talking about. I do now :)

[robertmuehsig]

@paillave Would #194 help?

[paillave]

Thanks @robertmuehsig . According to me, this solves the issue. I'll make an attempt from the moment I'm front of my screen.

[robertmuehsig]

Thanks - if you hit any other blocking issues just let me know. I try to push a new version to NuGet.org tomorrow.

Thanks for your patience!

[robertmuehsig]

0.0.11 with the fix should be ready on NuGet.org.

Hope this helps!

[paillave]

Just tested, works great. Thx!