Mocha: Error after updating to 6.1.0

Created on 7 Apr 2019  Â·  24Comments  Â·  Source: mochajs/mocha

$ yarn test
yarn run v1.3.2
(node:6135) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
warning package.json: License should be a valid SPDX license expression
$ NODE_ICU_DATA='node_modules/full-icu' nyc mocha test/test
: No such file or directory

full log: https://travis-ci.com/njzjz/chemicaltools-js/jobs/190964352

But it worked fine before.

Sent from PPHub For GitHub

confirmed-bug

Most helpful comment

Since mocha is already using prettier, the easy fix would be to change the prettier config in package.json to enforce specific line endings instead of just keeping whatever is there, and to ensure that prettier gets run before publishing...

// in package.json:
...
"scripts": {
  "prepublishOnly": "nps format test clean build",
},
"prettier": {
  "endOfLine": "nl"
}

All 24 comments

I just ran into this too. If you just run mocha without anything wrapping it the problem becomes clearer:

$ mocha
env: node\r: No such file or directory

It seems the package was published with CRLF line endings, which will cause issues on non-windows platforms:

$ file *.js bin/* lib/*.js
browser-entry.js:       ASCII text, with CRLF line terminators
index.js:               ASCII text, with CRLF line terminators
mocha.js:               UTF-8 Unicode text, with very long lines, with CRLF, LF line terminators
bin/_mocha:             a /usr/bin/env node script text executable, ASCII text, with CRLF line terminators
bin/mocha:              a /usr/bin/env node script text executable, ASCII text, with CRLF line terminators
bin/options.js:         ASCII text, with CRLF line terminators
lib/context.js:         ASCII text, with CRLF line terminators
lib/errors.js:          ASCII text, with CRLF line terminators
lib/growl.js:           ASCII text, with CRLF line terminators
lib/hook.js:            ASCII text, with CRLF line terminators
lib/mocha.js:           ASCII text, with CRLF line terminators
lib/pending.js:         ASCII text, with CRLF line terminators
lib/runnable.js:        ASCII text, with CRLF line terminators
lib/runner.js:          UTF-8 Unicode text, with CRLF line terminators
lib/stats-collector.js: ASCII text, with CRLF line terminators
lib/suite.js:           ASCII text, with CRLF line terminators
lib/test.js:            ASCII text, with CRLF line terminators
lib/utils.js:           ASCII text, with CRLF line terminators

yeah, shebang in /bin/mocha got broken because of the \r.
This renders mocha cli useless on many Unix-based systems (I use Fedora).
@juergba

yes, I have seen it. I'm working on it. Any suggestions?

I agree with @jasonk and @AviVahl that the \r on the shebang line is causing breakage. I just wanted to note that the shebang is automatically fixed during installation by npm v5.4.0 and later (due to npm/npm@0ef320cb4 from npm/npm#16634). So the breakage is conditional on the version of npm used to install mocha.

@juergba thx for the quick response.
check this out: https://help.github.com/en/articles/dealing-with-line-endings
you might want to add a .gitattributes file to the repo and rerelease with LF line endings.

@kevinoid I personally use latest [email protected] and it breaks there...

@AviVahl Does yarn change the shebang line itself? If not, that would explain why yarn is also affected.

Came here to suggest the gitattributes approach as well. It'll force LF checkouts on all platforms; I add one religiously to all new projects.

* text=auto EOL=LF

EDIT: also add an editorconfig forcing LF line endings if you haven't already.

@kevinoid I guess they leave the file untouched. AFAIK, on Linux, yarn basically creates symlink from .bin to the file specified in the "bin" field of the package's package.json. If that file was published with CRLF, it breaks. This is unlike the Windows behavior, where a proxy .cmd file is auto-created by yarn/npm.

@cspotcode can we chat please on gitter?

Since mocha is already using prettier, the easy fix would be to change the prettier config in package.json to enforce specific line endings instead of just keeping whatever is there, and to ensure that prettier gets run before publishing...

// in package.json:
...
"scripts": {
  "prepublishOnly": "nps format test clean build",
},
"prettier": {
  "endOfLine": "nl"
}

FYI this makes Travis tests fail when using Node 6.

CircleCI is broken as well using Node 10.

@AlexZeitler on Unix as well?

@juergba Not on my local machine (Ubuntu 18.04) but in CircleCI:
https://circleci.com/gh/PDMLab/httpproblem/15

@juergba thanks for addressing this.

I'm surprised that the smoke test in CI didn't catch this issue.

If you want help setting up CI on other platforms (mac on travis and windows on appveyor), I'd be happy to help you do that (the PR is not that much work, it's mostly creating the appveyor account, which has to be done by a committer).

@mceachen
Thanks, we have windows tests on appveyor. It seems pushing to github was fine, just npm publish went wrong.

The problem was the npm publish command run on Windows produced a tarball
that could not run on Linux. I don't think the smoke test deals with that.

On Sun, Apr 7, 2019, 6:24 PM Matthew McEachen notifications@github.com
wrote:

@juergba https://github.com/juergba thanks for addressing this.

I'm surprised that the smoke test in CI
https://travis-ci.org/mochajs/mocha/jobs/516888314 didn't catch this
issue.

If you want help setting up CI on other platforms (mac on travis and
windows on appveyor), I'd be happy to help you do that (the PR is not that
much work, it's mostly creating the appveyor account, which has to be done
by a committer).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mochajs/mocha/issues/3866#issuecomment-480635127, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAW-uDEzRttsy4OWTDWZN_oRU1KzEBoKks5venAggaJpZM4cg2Uz
.

@juergba Upgrading to 6.1.1 fixed it :+1:

@AlexZeitler thank you for your confirmation!

@mceachen
Thanks, we have windows tests on appveyor.

Ah, that's great. I didn't see a badge for the build in the header of the README.

The problem was the npm publish command run on Windows produced a tarball
that could not run on Linux. I don't think the smoke test deals with that.

@juergba How did you fix this?

n/m, .gitattributes change.

Was this page helpful?
0 / 5 - 0 ratings