Every time I download a project from github I run npm install, which triggers a reindex on the to-be-created node_modules folder. This indexing slows my computer way down. An ugly workaround is to create an empty node_modules folder, exclude it, then run npm install. How can i disable indexing for the node_modules folder in EVERY project by default? Webstorm does this for Meteor projects with .meteor/local, so I assume it's possible.
We usually suggest excluding this folder if it's used for auxiliary purposes (running grunt/gulp/karma, etc.). But we can't exclude it by default, as users developing Node.js applications usually need to have completion/types resolving working for node_modules.
If you need it being excluded from all your projects by default, just add node_modules to 'Ignore files and folders' list in Settings/Editor/File types
Update: since 2016.x, node_modules are auto-excluded by default. Direct dependencies listed in package.json are set up as a JavaScript Library for completion
webstorm treats node_module directory as library root, so there is no mark directory as menu when right click on it. we can change it to a plain directory by delete a config item whose type is project from preference > Language & Framework > Javascript > Libraries, then mark the node_module directory as excluded.
Related
I can't un-exclude node_modules in WebStorm 2018.2.3.
When I click to uncheck excluded nothing happens. I tried restarting my IDE and my laptop but got the same result.
Is there a reason? I found this link (for an older version of WebStorm) but it doesn't work for me: Can't remove node_modules from excluded folders in WebStorm
WebStorm auto-excludes node_modules folder from the project for better performance, but it's excluded only partially: direct project dependencies listed in package.json are added to JavaScript libraries for completion/navigation and thus indexed.
You can still un-exclude certain folders explicitly by choosing Mark directory as | Not excluded from folder right-click menu in the Project tree on the left. But note that un-excluding the node_modules folder would have negative performance impact.
See also WEB-24765
Thanks a lot for your answer. I manage to did it's not very proper way : I delete node_modules from my git repo then i push -f to my repo it works but your solution seems better. Unfortunately I've tried to unexclude (as I explained before) in Webstorm preferences but it has no effects. That's why I did that.
I want to install gulp-babel and babel-preset-es2015 in my project in WebStorm 2017, but after I install them in node_modules it is very slow to reopen the project in WebStorm. I have excluded the node_modules like this:
I can't use babel to transform the ES6 files. WebStorm becomes very slow and it stucks.
Please exclude the build destination folder ('dist' in your project) from the project: right-click on it in the Project view and select Mark as Excluded. It seems that the build process generates the files in the 'dist' folder on changes and the IDE keeps re-analyzing them considering them new files.
Seems that in the latest WebStorm (2016.2.3?), node_modules is marked as an excluded directory by default. There are certain directories within node_modules that I want to include in my project files and searches. So I used to go to Preferences > Directories and exclude all of the modules I didn't need. However, I'm not able to "unexclude" the parent node_modules anymore. I have also tried unchecking the option in Preferences > Languages > JavaScript > Libraries without luck.
Same question with screenshot, if needed: Can't remove node_modules from excluded folders in WebStorm
Found out that when you have a package.json file, the node_modules is automatically excluded. Since you probably don't want to remove that, you could create an additional lib folder with symlinks to each module you want to include from node_modules.
If you are on Windows, you can use the mklink command for this, in Linux/Mac the file manager might have a Make link option, or just use ln -s node_modules/socket.io lib/ from the command line.
You could also install the modules you need indexed into subfolder/node_modules, with subfolder having no package.json, and only the top-level node_modules folder will be marked as library.
Related issue: https://youtrack.jetbrains.com/issue/WEB-22909
I'm new to TeamCity, migrating from a different CI product, and trying to figure out how to configure a working build for a c++ project on version 9.1.6 of TeamCity.
The problem I'm having is that the agent is deleting my dependency directories right before (or during) the component build, and I can't find a record of why this is happening anywhere in the build log.
The build layout for any component in the system looks like so:
<base-dir>
|
+---<to-be-built>
+---<dependency-1>
+---Include
+---Lib
+---<dependency-2>
+---Include
+---Lib
...so, whatever the checkoutDir is for the component, it is assumed that all dependencies will be found in peer directories, named after the dependency, with no version information in the folder name.
For example, if version 3.0.2 of "MyExe" depends on version 1.1.0 of "SomeLibA" and version 2.1.0 of "SomeLibB", the file system should look like so:
MyExe_3.0.2
|
+---MyExe
+---SomeLibA
+---Include
+---Lib
+---SomeLibB
+---Include
+---Lib
So, to create this build layout, the build configuration for version 3.0.2 of "MyExe" has specified a custom checkout directory like so: "MyExe_3.0.2/MyExe".
So far, so good. The dependencies are configured as artifact dependencies and their destination directory is specified as '../'. This also seems straightforward.
When I kick off the build, though, I see the to-be-built component being retrieved, then I see the dependencies arrive, and then the gradle task I've configured for the build runs, and right at that moment, or just before, all of the dependency directories (SomeLibA and SomeLibB) get wiped out, and of course the component can't find any of its dependencies' include files and compilation fails.
I've turned off 'Clean all files in the checkout directory' on the component and 'Clean destination paths before downloading artifacts' on all dependencies, but this has no effect.
I've only found 2 hints possibly related to this behavior, but I'm not sure why either of them would be causing this problem.
The first is a little warning symbol on the Version Control Settings tab for "MyExe" which says "This directory might be cleaned by TeamCity before the build", referring to the custom directory. But, the directory that's getting cleaned out during the build run is not the checkout directory, it's the checkout directory's parent directory.
The only other possible candidate I can find is that the gradle task I've configured isn't the only task specified when the build runs. Instead of seeing "gradlew.bat myGradleTask" in the build log, I'm seeing "gradlew.bat --init-script C:\TeamCity\BuildAgent\plugins\gradle-runner\scripts\init.gradle myGradleTask".
But, I've looked through that init script, and didn't see anything related to directory cleanup.
I'm stumped. Does anyone have an idea what is going on, and how to work around it so this build can complete successfully? Acceptable solutions have to preserve the build layout requirements above.
The problem here was in disabling "Clean all files in the checkout directory before the build".
Disabling this checkbox has the effect of wiping out the contents of the entire path to the checkout directory.
For reference, see documentation here:
https://confluence.jetbrains.com/display/TCD9/Clean+Checkout
...from which the relevant excerpt is:
Automatic Clean Checkout
If clean checkout is not enabled, TeamCity updates the sources in the
checkout directory incrementally to the required state. TeamCity tries
to detect if the sources in the checkout directory are not
corresponding to the expected state and triggers clean checkout in
such cases to ensure sources are appropriate.
This means that under certain circumstances TeamCity can detect clean
checkout is necessary even if it is not enabled in the VCS settings
and not requested by the user from web UI. In such cases all the
content of the checkout directory is deleted and it is re-populated by
the sources from scratch. If any details are available on the
decision, they are added into the build log before checkout-related
logging.
Enabling this checkbox had the effect of leaving the dependency directories in place.
Our company might be moving from CVS to Subversion soon. This has brought about an issue for us, which I am trying to solve.
For CVS and Eclipse, we were able to use team project set files to gather various modules and check them out together (http://vpms.de.csc.com/projectset/). This made it very easy to manage projects, since there was no need to remember each module in the project.
However, project sets do not support SVN. I know there is an 'externals' property for SVN that does approximately (or possible exactly) the same thing. I tried this. Now, for the problem:
When I use the externals property and checkout 2 modules in eclipse, their C/C++ project properties are lost, and so I cannot right click on them to say "build project" or "clean project". They appear to Eclipse to be folders with files in them.
Is there something I am missing here?
EDIT
When I check out each module separately, they check out as projects, so they do have the individual .project/.cproject/settings stuff
You forgot to place Eclipse project metadata into your source control system. Make sure all files starting with '.' in project root make it in along with the entire contents of the .settings directory.
Subversion externals simply allows you to take files from one part of the repository and bring them in under a folder in your local checkout. At my last company, we had a java source directory that called "commonSrc" that was an SVN External for another project's main "src" directory, but in the project it was brought into, it simply acted as another folder (as you are experiencing).
I never really liked that method and wouldn't recommend it unless you have only one/two modules.
In order to do what you are trying to do with SVN, you might have to checkout each project separately, and use "Module Dependencies" in the project's properties to create the proper dependencies in Eclipse. You might be able to commit these project files so that the next person doesn't have to re-link them.
In case anyone needs this, here's what I found:
http://vpms.de.csc.com/projectset/
&
http://www.polarion.org/index.php?page=download&project=subversive
OR
http://www.giniality.com/old/update/projectset/
for Subversion + Project Set integration.
There is no need to break your project set. Once you have the integration plugins installed in Eclipse, all you need to do is change the source from the CVS server to SVN.