search

plantain-00 / type-coverage

A CLI tool to check type coverage for typescript code
MIT License
1.2k stars 43 forks source link

type-coverage -p command yielding different results from different root directories #123

Closed spaul1042 closed 1 year ago

spaul1042 commented 1 year ago

Version(if relevant): 1.0.0

Environment(if relevant):

Vs code , React Typescript based project

Code(if relevant):

// code here

Expected:

I have a packages folder where there are different packages whose type-coverage rate I want to calculate. There is a package named "board" and another package named "proto".

I am testing the type-coverage commands on these two terminals. In Terminal 1 , I am in >> src/packages/ In Terminal 2 , I am in >> src/packages/proto

Command I run on Terminal 1 : type-coverage -p board Command I run on Terminal 2 : type-coverage -p ../board

I must get the same type coverage rate in bot the terminals.

Actual:

On Terminal 1 I get >> 396027/40714, 97.27 % On Terminal 2 I get >> 608/662. 91.84 %

Am I missing something here as the type-coverage command is installed globally.

plantain-00 commented 1 year ago

The result in files start with .. will be ignored, to fix #42 : https://github.com/plantain-00/type-coverage/blob/7aa9475f7ef8c3b15f994a7b4bd88496f919ceed/packages/core/src/core.ts#L43-L45

spaul1042 commented 1 year ago

I want to run type-coverage commands from script file of a directory named type-coverage present in the script directory. and script folder is there in the root of the project. do you suggest something that I can do?

spaul1042 commented 1 year ago

The result in files start with .. will be ignored, to fix #42 :

https://github.com/plantain-00/type-coverage/blob/7aa9475f7ef8c3b15f994a7b4bd88496f919ceed/packages/core/src/core.ts#L43-L45

plantain-00 commented 1 year ago

Maybe your script can be like something cd .. && type-coverage -p ./src

spaul1042 commented 1 year ago

My issue got resolved, I had to change my cwd in the script file. But please look into this that the command not working when I cd into a particular package of the packages directory , and then run type-coverage -p . Even this yielding a different answer.

plantain-00 commented 1 year ago

v2.26.0 add --not-only-in-cwd to disable this behavior.

spaul1042 commented 1 year ago

Okay thanks!

spaul1042 commented 1 year ago

Hi, I have a doubt regarding type-coverage library. I have been using the type-coverage library for one of my projects since last one week and I really appreciate the potential it holds.

But There is a constant error I get , when I run the type-coverage -p command on a few of my packages. The command works fine for the rest of my packages. the error is : FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

I am mentioning the entire error below here. Can you please tell me what's the issue here?

<--- Last few GCs --->

[16383:0x150008000] 73608 ms: Mark-Compact 4034.5 (4131.1) -> 4019.9 (4132.6) MB, 869.79 / 0.00 ms (average mu = 0.118, current mu = 0.043) allocation failure; scavenge might not succeed [16383:0x150008000] 74686 ms: Mark-Compact 4036.0 (4132.6) -> 4021.4 (4134.1) MB, 1045.12 / 0.00 ms (average mu = 0.072, current mu = 0.030) allocation failure; scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory 1: 0x100710308 node::Abort() [/opt/homebrew/Cellar/node/20.1.0/bin/node] 2: 0x100711814 node::ModifyCodeGenerationFromStrings(v8::Local, v8::Local, bool) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 3: 0x100878fbc v8::Utils::ReportOOMFailure(v8::internal::Isolate, char const, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 4: 0x100878f68 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate, char const, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 5: 0x100a078bc v8::internal::Heap::CallGCPrologueCallbacks(v8::GCType, v8::GCCallbackFlags, v8::internal::GCTracer::Scope::ScopeId) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 6: 0x100a0a5d8 v8::internal::Heap::ComputeMutatorUtilization(char const, double, double) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 7: 0x100a08534 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 8: 0x100a063b8 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 9: 0x1009fd994 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 10: 0x1009fe0f8 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 11: 0x1009e6df4 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 12: 0x100d09cc8 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long, v8::internal::Isolate) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 13: 0x100548c44 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/opt/homebrew/Cellar/node/20.1.0/bin/node] 14: 0x1004f1038 Builtins_ArrayPrototypePush [/opt/homebrew/Cellar/node/20.1.0/bin/node] 15: 0x1093b3724 16: 0x1096fa478 17: 0x1097ccaf4 18: 0x1091ad8c0 19: 0x1097cc978 20: 0x107f27554 21: 0x1099f6dc4 22: 0x10934a0d8 23: 0x1095cf550 24: 0x109589df4 25: 0x109888acc 26: 0x107f30624 27: 0x107e1b8fc 28: 0x107f8d4cc 29: 0x109908d90 30: 0x10840e660 31: 0x109373c44 32: 0x108419e1c 33: 0x107e77c24 34: 0x107f8d3c0 35: 0x1099128d0 36: 0x107e090ec 37: 0x107e6d290 38: 0x109aaf16c 39: 0x1099f6988 40: 0x107e3a3b0 41: 0x109aba0dc 42: 0x109b3300c 43: 0x109b2ed10 44: 0x109a6a070 45: 0x109b2ee88 46: 0x109b30da8 47: 0x109a638f8 48: 0x1093d3ebc 49: 0x1098d3d58 50: 0x1004f7210 Builtins_AsyncFunctionAwaitResolveClosure [/opt/homebrew/Cellar/node/20.1.0/bin/node] 51: 0x1005a4fb8 Builtins_PromiseFulfillReactionJob [/opt/homebrew/Cellar/node/20.1.0/bin/node] 52: 0x1004e6b94 Builtins_RunMicrotasks [/opt/homebrew/Cellar/node/20.1.0/bin/node] 53: 0x1004be3f4 Builtins_JSRunMicrotasksEntry [/opt/homebrew/Cellar/node/20.1.0/bin/node] 54: 0x1009913a8 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 55: 0x10099183c v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 56: 0x1009b3254 v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 57: 0x1009b3088 v8::internal::MicrotaskQueue::PerformCheckpointInternal(v8::Isolate) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 58: 0x100638b10 node::InternalCallbackScope::Close() [/opt/homebrew/Cellar/node/20.1.0/bin/node] 59: 0x100639064 node::InternalMakeCallback(node::Environment, v8::Local, v8::Local, v8::Local, int, v8::Local, node::async_context) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 60: 0x100655138 node::AsyncWrap::MakeCallback(v8::Local, int, v8::Local) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 61: 0x1007176a4 node::fs::FSReqCallback::Resolve(v8::Local) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 62: 0x10071a104 node::fs::AfterScanDir(uv_fs_s) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 63: 0x10070a3c8 node::MakeLibuvRequestCallback<uv_fs_s, void ()(uv_fs_s)>::Wrapper(uv_fs_s) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 64: 0x1033f6ff0 uvwork_done [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib] 65: 0x1033fa3c4 uv__async_io [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib] 66: 0x10340a1e0 uvio_poll [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib] 67: 0x1033fa7bc uv_run [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib] 68: 0x100639964 node::SpinEventLoopInternal(node::Environment) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 69: 0x1007533c4 node::NodeMainInstance::Run(node::ExitCode, node::Environment) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 70: 0x100753114 node::NodeMainInstance::Run() [/opt/homebrew/Cellar/node/20.1.0/bin/node] 71: 0x1006d8a24 node::LoadSnapshotDataAndRun(node::SnapshotData const*, node::InitializationResultImpl const) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 72: 0x1006d8c0c node::Start(int, char**) [/opt/homebrew/Cellar/node/20.1.0/bin/node] 73: 0x19e2d7f28 start [/usr/lib/dyld]

On Wed, May 24, 2023 at 12:28 PM York Yao @.***> wrote:

v2.26.0 add --not-only-in-cwd to disable this behavior.

— Reply to this email directly, view it on GitHub https://github.com/plantain-00/type-coverage/issues/123#issuecomment-1560554917, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASF7BA3IB67JZLTIVWYE2X3XHWWPXANCNFSM6AAAAAAYLJ6DPU . You are receiving this because you modified the open/close state.Message ID: @.***>