-
-
Notifications
You must be signed in to change notification settings - Fork 360
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
nyc does not work with symlinks #1301
Comments
Please alter your |
@coreyfarrell In my project the So this solution won't work because nyc is ran from the project folder. So to better illustrate my structure I have updated the repo: aalexgabi/nyc-symlink-problem@5eba65d It tried with these include patterns but it still does not work:
|
Coverage of files outside the project isn't supported. It might work for you to tweak your settings as follows: "cwd": "..",
"include": [
"project/src/**",
"lib/**"
] The |
@coreyfarrell Thank you for the cwd option (I found it in the meanwhile here: https://stackoverflow.com/questions/53399098/enabling-nyc-istanbul-code-coverage-for-files-outside-the-package-directory). It would be nice if the cwd option would be documented. The files are inside the project folder in node_modules through a symlink. From a functional perspective the symlink should not change anything for nyc in my opinion. I get that the node uses realpath to determine if two modules are the same file but I think that nyc should abstract that away because it adds a lot of complexity in the configuration and also it forces the user to mix paths between projects otherwise. nyc should work the same if a package is downloaded from npm or is linked locally in development. The current behavior requires manually changing the .nycrc file each time you switch from using links to downloading a module. |
nyc works with realpaths. Changing this would be a major breaking change (IE for monorepos). I'd think you can configure nyc to include both paths (the locally linked any the npm install), but be aware that instrumenting packages downloaded from npm is a non-goal of this project (thus why node_modules is ignored by default). I appreciate that nyc is not working exactly as you would like but it is working the way it needs to work to support normal project configurations. What you are asking for may simplify what you are trying to do but for others (again monorepo projects is the major issue), including @AndrewFinlay any thoughts on clarifications to the README for the |
Not necessarily. It all depends on how the change is implemented.
I am not asking to make it more difficult at all. I am asking that:
It would be very useful if nyc would have support for both symlinks and realpaths because they are both valid from a functional perspective. There would be no breaking change because adding support for symlinks does not mean removing support for realpaths. |
If someone wants to create a patch for this I would review it for potential merge as long as it does not introduce any changes to existing projects (current realpath functionality must be default). I do worry about the potential for errors that using this option might cause. I believe the process for enabling what you've requested would be:
|
@coreyfarrell thanks for the "cwd": "..",
"include": [
"packageA",
"packageBRequiresPackageA"
] Think it would be worth documenting this for people using monorepos |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
I reproduced the issue in this repo: aalexgabi/nyc-symlink-problem@3ce1fe8
When I don't use a symlink it does work: aalexgabi/nyc-symlink-problem@9da9355
This was reported many times (not sure all issues here are due to symlinks) but not fixed:
Expected Behavior
I should have symlinked files from node_modules included:
Observed Behavior
I don't have symlinked files from node_modules included:
Troubleshooting steps
cache: false
in my nyc configEnvironment Information
The text was updated successfully, but these errors were encountered: