profile
viewpoint
Igor Novozhilov IgorNovozhilov Russia, Yaroslavl

eslintcc/eslintcc 10

ESLint - JavaScript Complexity of Code

IgorNovozhilov/UserScript 2

My UserScript

IgorNovozhilov/brackets-linux-menu 1

Красивые стили для нестандартного меню Brackets в Linux

IgorNovozhilov/babel-hook-esm-to-cjs-package-type-runtime 0

Deprecated, see https://github.com/nodutilus/nyc-config

IgorNovozhilov/CodeClimber 0

Сервис сбора метрик и проверки качества кода

IgorNovozhilov/eslint-plugin-jsdoc 0

JSDoc specific linting rules for ESLint.

IgorNovozhilov/InsideTensorUserStyle 0

Генератор пользовательских стилей для inside

IgorNovozhilov/jekyll-autodoc-components 0

Components for auto-documentation, based on jekyll

PR opened istanbuljs/nyc

feat: Add support to change files tree in reporter . --summarizer=flat|nested|pkg option

During debug i found there is no way to change how files are represented in report (flat, tree, etc) despite this feature is available in istanbul-lib-report package that generates files nodes tree for report. This allows to pass override of this feature from nyc down to istanbul-lib-report

+15 -0

0 comment

2 changed files

pr created time in 7 hours

issue commentistanbuljs/nyc

`return 0n` breaks nyc coverage

Thank you @coreyfarrell !

philz

comment created time in 10 hours

issue commentistanbuljs/nyc

Question: can you check coverage on a per-file basis?

I think jest provides a neat feature to allow for individual files thresholds, does not look like a complicated effort although i have not looked deeply into the checkCoverage code, jest's impl seems reasonably simple, any chance we can get something along those lines?

MrSimonEmms

comment created time in 17 hours

issue closedistanbuljs/nyc

`return 0n` breaks nyc coverage

<!--Please use the template provided below when reporting bugs:-->

Link to bug demonstration repository

https://github.com/philz/nyc-bug is a one-file, 4-line repro. I encountered this bug in a large TypeScript code base, and I was able to work around it with assigning the bigint to a variable, but this was very surprising.

Expected Behavior

Coverage should work.

Observed Behavior

The instrumented code is return0n rather than return 0n, or so it seems.

$./node_modules/.bin/nyc node index.js
/Users/philip/src/nyc-bug/index.js:2
cov_235y2cz5ul=function(){return actualCoverage;};}return actualCoverage;}cov_235y2cz5ul();function f(){cov_235y2cz5ul().f[0]++;cov_235y2cz5ul().s[0]++;return0n;}cov_235y2cz5ul().s[1]++;f();
                                                                                                                                                        ^

ReferenceError: return0n is not defined
    at f (/Users/philip/src/nyc-bug/index.js:2:153)
    at Object.<anonymous> (/Users/philip/src/nyc-bug/index.js:2:187)
    at Module._compile (internal/modules/cjs/loader.js:955:30)
    at Module.replacementCompile (/Users/philip/src/nyc-bug/node_modules/append-transform/index.js:60:13)
    at Module._extensions..js (internal/modules/cjs/loader.js:991:10)
    at Object.<anonymous> (/Users/philip/src/nyc-bug/node_modules/append-transform/index.js:64:4)
    at Module.load (internal/modules/cjs/loader.js:811:32)
    at Function.Module._load (internal/modules/cjs/loader.js:723:14)
    at Function.Module.runMain (internal/modules/cjs/loader.js:1043:10)
    at internal/main/run_main_module.js:17:11
----------|---------|----------|---------|---------|-------------------
File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
----------|---------|----------|---------|---------|-------------------
All files |     100 |      100 |     100 |     100 |                   
 index.js |     100 |      100 |     100 |     100 |                   
----------|---------|----------|---------|---------|-------------------

Troubleshooting steps

c8 works fine with this. I've tried upgrading nyc, but my demo repo has a recent version installed.

Environment Information

This happens on Linux as well.

<!-- [mandatory] run the following script: npx envinfo@latest --preset nyc -->

$npx envinfo@latest --preset nyc
npx: installed 1 in 1.846s

  System:
    OS: macOS 10.15.7
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 173.98 MB / 32.00 GB
  Binaries:
    Node: 12.14.1 - ~/h/node/env-12.14.1/bin/node
    Yarn: 1.21.1 - ~/h/node/env-12.14.1/bin/yarn
    npm: 6.13.4 - ~/h/node/env-12.14.1/bin/npm
  npmPackages:
    nyc: ^15.1.0 => 15.1.0 

closed time in 20 hours

philz

issue commentistanbuljs/nyc

`return 0n` breaks nyc coverage

Closing this issue as a fix to the associated bug has been merged to the main branch of babel. The fix will be available upon the next release of @babel/generator.

philz

comment created time in 20 hours

issue commenttc39/proposal-class-fields

Properties without initializers can create some headache in "real-world" scenarios.

Not declaring the field is a no-go for Typescript users.

This is a solved problem, since TS uses the declare keyword.

dfahlander

comment created time in 2 days

issue commenttc39/proposal-class-fields

Properties without initializers can create some headache in "real-world" scenarios.

I agree that it's by no means desirable to have to resort to such constructs. However, it's also not like there's much in the way of better options. Defining the field on the instance at construction time will lead to the problem described. Not declaring the field is a no-go for Typescript users. Are there any other possibilities?

dfahlander

comment created time in 2 days

issue closedistanbuljs/nyc

There is a Vulnerability in nyc 15.1.0

Description

There is a vulnerability in y18n: https://snyk.io/test/npm/nyc/15.1.0

Solution

Try to update / upgrade yargs.

closed time in 2 days

martinoppitz

issue commentistanbuljs/nyc

There is a Vulnerability in nyc 15.1.0

@bcoe thanks for taking care of this!

Closing this ticket as an in-range update is now available.

martinoppitz

comment created time in 2 days

issue commentistanbuljs/nyc

There is a Vulnerability in nyc 15.1.0

@coreyfarrell I have released y18n@4.0.1 which has the patch.

martinoppitz

comment created time in 2 days

issue commentistanbuljs/nyc

`return 0n` breaks nyc coverage

Thanks for the repository, I've investigated and this looks like a bug in babel. I've reported at https://github.com/babel/babel/issues/12423.

The workaround for now is to set compact: false in your nyc configuration.

philz

comment created time in 3 days

issue openedistanbuljs/nyc

`return 0n` breaks nyc coverage

<!--Please use the template provided below when reporting bugs:-->

Link to bug demonstration repository

https://github.com/philz/nyc-bug is a one-file, 4-line repro. I encountered this bug in a large TypeScript code base, and I was able to work around it with assigning the bigint to a variable, but this was very surprising.

Expected Behavior

Coverage should work.

Observed Behavior

The instrumented code is return0n rather than return 0n, or so it seems.

$./node_modules/.bin/nyc node index.js
/Users/philip/src/nyc-bug/index.js:2
cov_235y2cz5ul=function(){return actualCoverage;};}return actualCoverage;}cov_235y2cz5ul();function f(){cov_235y2cz5ul().f[0]++;cov_235y2cz5ul().s[0]++;return0n;}cov_235y2cz5ul().s[1]++;f();
                                                                                                                                                        ^

ReferenceError: return0n is not defined
    at f (/Users/philip/src/nyc-bug/index.js:2:153)
    at Object.<anonymous> (/Users/philip/src/nyc-bug/index.js:2:187)
    at Module._compile (internal/modules/cjs/loader.js:955:30)
    at Module.replacementCompile (/Users/philip/src/nyc-bug/node_modules/append-transform/index.js:60:13)
    at Module._extensions..js (internal/modules/cjs/loader.js:991:10)
    at Object.<anonymous> (/Users/philip/src/nyc-bug/node_modules/append-transform/index.js:64:4)
    at Module.load (internal/modules/cjs/loader.js:811:32)
    at Function.Module._load (internal/modules/cjs/loader.js:723:14)
    at Function.Module.runMain (internal/modules/cjs/loader.js:1043:10)
    at internal/main/run_main_module.js:17:11
----------|---------|----------|---------|---------|-------------------
File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
----------|---------|----------|---------|---------|-------------------
All files |     100 |      100 |     100 |     100 |                   
 index.js |     100 |      100 |     100 |     100 |                   
----------|---------|----------|---------|---------|-------------------

Troubleshooting steps

c8 works fine with this. I've tried upgrading nyc, but my demo repo has a recent version installed.

Environment Information

This happens on Linux as well.

<!-- [mandatory] run the following script: npx envinfo@latest --preset nyc -->

$npx envinfo@latest --preset nyc
npx: installed 1 in 1.846s

  System:
    OS: macOS 10.15.7
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 173.98 MB / 32.00 GB
  Binaries:
    Node: 12.14.1 - ~/h/node/env-12.14.1/bin/node
    Yarn: 1.21.1 - ~/h/node/env-12.14.1/bin/yarn
    npm: 6.13.4 - ~/h/node/env-12.14.1/bin/npm
  npmPackages:
    nyc: ^15.1.0 => 15.1.0 

created time in 3 days

issue commenttc39/proposal-class-fields

Properties without initializers can create some headache in "real-world" scenarios.

That works, but it isn't desirable to write code that way.

dfahlander

comment created time in 7 days

PublicEvent

issue closedistanbuljs/nyc

Does not work with tape?

Expected Behavior

should work with tape out of box

Observed Behavior

version 15+ cannot detect files. version 14.1.1 works good

Troubleshooting steps

  • [x] still occurring when I put cache: false in my nyc config
npm i nyc@15.1.0 tape@5.0.1
npx nyc tape test.js

code.js

module.exports = {
  foo: () => true,
  bar: () => {
    if (process.env.FOO) {
      return process.env.BAR
    }
  }
}

test.js

const test = require('tape')
const code = require('./code')

test('nyc should work', t => {
  t.ok(code.foo(), 'should pass')
  t.end()
})

Environment Information

  System:
    OS: Linux 4.19 Debian GNU/Linux 10 (buster) 10 (buster)
    CPU: (2) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 344.86 MB / 1.92 GB
  Binaries:
    Node: 12.18.2 - ~/.nvm/versions/node/v12.18.2/bin/node
    npm: 6.14.5 - ~/.nvm/versions/node/v12.18.2/bin/npm

closed time in 12 days

clarkttfu

issue commentistanbuljs/nyc

Does not work with tape?

Hi, it works with v12.19.0 indeed.

With node version 12.14 it cannot locate files and output something like:

----------|---------|----------|---------|---------|-------------------
File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------|---------|----------|---------|---------|-------------------
All files |       0 |        0 |       0 |       0 |
----------|---------|----------|---------|---------|-------------------
clarkttfu

comment created time in 12 days

issue commentistanbuljs/nyc

Using NYC with ecomcon

I don't know what to suggest as I know nothing about ecomcon. One comment nyc has some rough edges with the cwd setting, it's better to ensure process.cwd() contains all code. Source maps should not point outside the cwd either.

visaudi

comment created time in 12 days

issue commentistanbuljs/nyc

Using NYC with ecomcon

Do you want me to do some leg work to figure out what’s going on?

What should I find out for you?

Thanks so much!

On Fri, Nov 20, 2020 at 9:54 AM Corey Farrell notifications@github.com wrote:

I suspect ecomcon is hijacking the require process instead of injecting itself, thus blocking nyc from injecting coverage counters. I don't know how/if this can be solved, I don't have time to dig into ecomcon.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/istanbuljs/nyc/issues/1352#issuecomment-731249844, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWJ3TUMNA25HO7KVB26KGTSQ2GKNANCNFSM4RNIOZVQ .

visaudi

comment created time in 13 days

issue closedistanbuljs/nyc

Unexpected token / in JSON at position 58

If I run nyc I get the error

Unexpected token / in JSON at position 58

Expected Behavior

It executes.

Observed Behavior

Unexpected token / in JSON at position 58

Environment

System: OS: Linux 4.19 Ubuntu 20.04.1 LTS (Focal Fossa) CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz Memory: 1.38 GB / 7.70 GB Binaries: Node: 14.3.0 - ~/.nvm/versions/node/v14.3.0/bin/node Yarn: 1.13.0 - /mnt/c/Users/james/AppData/Roaming/npm/yarn npm: 6.14.7 - ~/.nvm/versions/node/v14.3.0/bin/npm npmPackages: @babel/cli: ^7.10.5 => 7.10.5 @babel/core: ^7.10.5 => 7.10.5 @babel/plugin-transform-async-to-generator: ^7.10.4 => 7.10.4 @babel/plugin-transform-runtime: ^7.10.5 => 7.10.5 @babel/polyfill: ^7.10.4 => 7.10.4 @babel/preset-env: ^7.10.4 => 7.10.4 @babel/runtime: ^7.10.5 => 7.10.5 @types/source-map-support: ^0.5.2 => 0.5.2 babel-plugin-source-map-support: ^2.1.2 => 2.1.2 grunt-babel: ^8.0.0 => 8.0.0 grunt-mocha-istanbul: ^5.0.2 => 5.0.2 nyc: ^15.1.0 => 15.1.0 remap-istanbul: ^0.13.0 => 0.13.0 source-map-support: ^0.5.19 => 0.5.19 ts-node: ^8.10.2 => 8.10.2 typescript: ^3.9.7 => 3.9.7

closed time in 13 days

metawrap-dev

issue commentistanbuljs/nyc

Unexpected token / in JSON at position 58

You have a broken JSON file that is needed to start nyc. This is not a bug in nyc.

metawrap-dev

comment created time in 13 days

issue closedistanbuljs/nyc

NYC changes semantics of the program

Description:

Hello, I have an issue that I cannot resolve without your help.

When I use Nodejs to run the following program.js, the test is running OK. e.g: node program.js When I use NYC to get the coverage of the program, the test is failing due to timeout. e.g: nyc node program.js

After analyzing, I find that NYC changed the semantics of the program. In program.js, v1 > v0 returns False since the character b > a. But, after instrumenting, v1 > v0 returns True since the character 1 > 0. And then, the program enters an infinite loop.

Does NYC have an argument to limit program execution time? When the limit is exceeded, the process is killed. If not, Do you have some ways to break this infinite loop?

program.js:

var v0 = function (v1){
	var b = 1;
};
var v1 = function (v1){
	var a = 1;
};

console.log(v0<v1);

while(v0 < v1){
};

NYC instrument

cov_4ps048zci();
cov_4ps048zci().s[0]++;
var v0=function(v1){
	cov_4ps048zci().f[0]++;
	var b=(cov_4ps048zci().s[1]++,1);
};
cov_4ps048zci().s[2]++;
var v1=function(v1){
	cov_4ps048zci().f[1]++;
	var a=(cov_4ps048zci().s[3]++,1);
};
cov_4ps048zci().s[4]++;
console.log(v0<v1);
cov_4ps048zci().s[5]++;
while(v0<v1){};

closed time in 13 days

QuXing9

issue commentistanbuljs/nyc

NYC changes semantics of the program

nyc does change the output of fn.toString(), restoring the original fn.toString() is out of scope. If this is a requirement of your project I recommend looking into c8. Another option if this occurs in limited number of functions you could tell istanbul to ignore those two functions:

/* istanbul ignore next */
var v0 = function (v1){
	var b = 1;
};
/* istanbul ignore next */
var v1 = function (v1){
	var a = 1;
};

console.log(v0<v1);

while(v0 < v1){
};

Does NYC have an argument to limit program execution time? When the limit is exceeded, the process is killed. If not, Do you have some ways to break this infinite loop?

NYC does not have a feature for limiting program execution time. I'd suggest looking to your testing framework for this (mocha, tap, etc). That is where this sort of test timeout would be implemented.

QuXing9

comment created time in 13 days

issue commentistanbuljs/nyc

Using NYC with ecomcon

I suspect ecomcon is hijacking the require process instead of injecting itself, thus blocking nyc from injecting coverage counters. I don't know how/if this can be solved, I don't have time to dig into ecomcon.

visaudi

comment created time in 13 days

issue closedistanbuljs/nyc

Could JS engines be used as the test runner?

Hi! I tried to use js engines such as javascriptcore and chakra as the test runners, But nyc failed to get the coverages. After changing the test runner to nodejs, nyc got the coverages successfully. So I want to ask how to use the JS engine as the test runner correctly? Thx~

closed time in 13 days

QuXing9

issue commentistanbuljs/nyc

Could JS engines be used as the test runner?

nyc only provides direct support for node.js. Other engines likely have different methods for hooking calls to require and nyc does not support those hooks. Without additional maintainers we are not able to expand support to other engines.

QuXing9

comment created time in 13 days

issue commentistanbuljs/nyc

Does not work with tape?

I'm not able to reproduce this issue, I'm getting coverage with your example. Using node.js 12.19.0, not sure if 12.18.2 had an issue?

clarkttfu

comment created time in 13 days

issue commentistanbuljs/nyc

How to instrument code for Electron app?

You likely need to use babel-plugin-istanbul, though I don't have any specific instructions for doing this in electron or under ava-ts. This is a somewhat advanced topic which I don't have the knowledge to support.

Githubber2021

comment created time in 13 days

issue commentistanbuljs/nyc

There is a Vulnerability in nyc 15.1.0

nyc 15 will never drop support for node.js 8, doing so is semver major (node.js 8 being EOL is not relevant to this). nyc 16 will require node.js 10 but it is not going to be rushed out (no current timeframe for nyc 16 to be released). The only way this issue can possibly be hit is if the system environment variable LC_ALL is set to __proto__ before nyc runs. This would only happen if your system is compromised to begin with.

https://github.com/yargs/y18n/issues/112 is the upstream bug, if a fix is backported to y18n 4.x then yargs 15 and thus nyc 15 will be able to pull the fix per semver range.

Leaving this ticket open so others can see the status.

martinoppitz

comment created time in 13 days

PR closed istanbuljs/nyc

fix: upgrade yargs to v16 to fix a high vulnerability

Fix: https://github.com/istanbuljs/nyc/issues/1367

+9666 -59

1 comment

2 changed files

martinoppitz

pr closed time in 13 days

pull request commentistanbuljs/nyc

fix: upgrade yargs to v16 to fix a high vulnerability

This is not possible, nyc 15 supports node.js 8 so it cannot upgrade to yargs 16. I'll comment further on the issue.

martinoppitz

comment created time in 13 days

more