files using package word are not included in the coverage report
#796
Comments
nyc was hard-coded to use `esModules: true` when running the
instrumenter. This could result in certain scripts not being
instrumented.
```js
function package() {
return 'package is a reserved keyword'
}
console.log(package())
```
Using `--es-modules false` will allow this script to be instrumented.
Issue istanbuljs#796
|
@kevinrambaud I've posted a PR to add an option to allow this, but 'use strict';
function package() {
return 'package is reserved in strict mode';
}
console.log(package());The addition of |
|
hey @coreyfarrell I forgot to update the issue but I came to the same conclusion after having read the MDN docs https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode thanks for the update |
nyc was hard-coded to use `esModules: true` when running the
instrumenter. This could result in certain scripts not being
instrumented.
```js
function package() {
return 'package is a reserved keyword'
}
console.log(package())
```
Using `--es-modules false` will allow this script to be instrumented.
Issue istanbuljs#796
nyc was hard-coded to use `esModules: true` when running the
instrumenter. This could result in certain scripts not being
instrumented.
```js
function package() {
return 'package is a reserved keyword'
}
console.log(package())
```
Using `--es-modules false` will allow this script to be instrumented.
Issue istanbuljs#796
nyc was hard-coded to use `esModules: true` when running the
instrumenter. This could result in certain scripts not being
instrumented.
```js
function package() {
return 'package is a reserved keyword'
}
console.log(package())
```
Add command-line option `--es-modules true` to force strict parsing.
Issue istanbuljs#796
A previous fix for istanbuljs#796 added an es-modules option and set it false by default. This default was a change of behavior in NYC as previously all sources were parsed as ES modules by the instrumenter. I believe the old behavior is the correct default because it allows NYC to work with modern code. Code which uses certain features which violate strict mode will have to disable es-modules. This will not effect ES5 which follows the rules of 'use strict'.
A previous fix for #796 added an es-modules option and set it false by default. This default was a change of behavior in NYC as previously all sources were parsed as ES modules by the instrumenter. I believe the old behavior is the correct default because it allows NYC to work with modern code. Code which uses certain features which violate strict mode will have to disable es-modules. This will not effect ES5 which follows the rules of 'use strict'.
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This just popped up again, with the I think there should never be a case where nyc both (a) doesn't cover a file because of a transpilation error, and (b) says nothing about it. At the very least, a warning should be printed to stderr that coverage could not be added because of |
Expected Behavior
I expect
nycto cover all the files that are required by any modules that are tested by mocha.Observed Behavior
When using the
packageword into a file, either as a variable name of a function name,nycjust ignore the file and does not report anything for it.Bonus Points! Code (or Repository) that Reproduces Issue
https://github.com/kevinrambaud/nyc-package-word-empty-coverage-example
Forensic Information
Operating System: the operating system you observed the issue on.
Environment Information: information about your project's environment, see instructions below:
sh -c 'node --version; npm --version; npm ls' > output.txt
https://gist.github.com/kevinrambaud/400048f2bef65a061e6a2859613a23bc
The text was updated successfully, but these errors were encountered: