Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mocha not spawned due to long argument list? #154

Open
jvanoostveen opened this issue Feb 21, 2017 · 9 comments
Open

Mocha not spawned due to long argument list? #154

jvanoostveen opened this issue Feb 21, 2017 · 9 comments

Comments

@jvanoostveen
Copy link

With version 4, when trying to use gulp-mocha, I'm getting

 UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): Error in plugin 'gulp-mocha'
Message:
    spawn ENAMETOOLONG
Details:
    code: ENAMETOOLONG
    errno: ENAMETOOLONG
    syscall: spawn

It seems this is related to the passing of the files argument, which is quite large in our case (500+ entries).

Environment: Windows 10

@cedx
Copy link

cedx commented Feb 22, 2017

It seems to be an OS issue: Windows has a strong limit on the maximum length of a path (see: Maximum Path Length Limitation). So you should check that your paths are not too long for this OS.

Or you could try to increase this limit :

Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior.
A registry key allows you to enable or disable the new long path behavior. To enable long path behavior set the registry key at HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD).

@jvanoostveen
Copy link
Author

Hmm I was suspecting it to be Windows. Too bad I'm still on version 1511... And having to set registry keys to run the tests is not something friendly for the other developers.
I've for now reverted gulp-mocha back to v3.

In one of the tools we've been developing as a developer aid, we started mocha in a forked process and are using messages to send over the files to test (see: https://github.com/AFASResearch/typescript-assistant/blob/master/src/testing/mocha.ts#L68). This might be a nice solution for gulp-mocha as well?

@cedx
Copy link

cedx commented Feb 22, 2017

It could also be an issue with the maximum length of a command : as for paths, Windows is very limited (8191 characters) comparing to Linux systems (usually 131072 characters).

@tkirda
Copy link

tkirda commented Feb 24, 2017

Have the same issue on Windows 10, is the any way to pass a pattern?

Message:
    spawn undefined ENOENT
Details:
    errno: ENOENT
    code: ENOENT
    syscall: spawn undefined
    killed: false
    stdout:
    stderr: The command line is too long.

    failed: true
    signal: null

@jezzsantos
Copy link

On Windows 10, get same problem.
Changing to support long paths in windows, as described here: #154 (comment) did not fix it.

Reverting back to 3.0.1 fixed it.
Version 4.0.0 broke it again!

@gingur
Copy link

gingur commented Jul 19, 2017

Same issue here, why wouldn't this have been an issue in previous versions?

@cedx
Copy link

cedx commented Jul 19, 2017

@gingur In previous versions, this package called the Mocha API directly (EDIT: but it seems that this API has some severe issues). So, we hadn't any problem as the JavaScript API has no such limitations on Windows.

The v4 spawns instead the Mocha executable: the operating system limitations applies now.

@gingur
Copy link

gingur commented Jul 19, 2017

@cedx understood, we've reverted our dependency back down to @^3 for now, any plans on a feature to toggle this functionality via config to degrade back to previous functionality?

@cedx
Copy link

cedx commented Jul 27, 2017

Not the best solution, but personally, I ended up by no longer using the Gulp plugin and calling directly the Mocha executable.

For example: https://github.com/cedx/which.js/blob/master/gulpfile.js#L59

The OS limitations still applies... but the new way launches all my tests without using a long Shell command (like the one built by the plugin). So the issue is partially resolved on my side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants