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
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'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.
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.
In Netbeans when I create a new C++ project from existing sources only the Makefile appears to be under Git version control. The other files (.h, .cpp) all appear to be ignored (grayed out) when viewing from the Projects or Files windows in Netbeans.
How do I make these files tracked?
I have already tried the right-click unignore option.
I do not have a .gitignore file at this point.
You can ignore files in git in other ways than using the .gitignore.
In project folder check the file .git/info/exclude - you can exclude files which yu don't want to keep in .gitignore (which is usually shared with other coders)
You can also ignore files on a global level. Check the settings of Netbeans - it might have a global ignore list used by git.
I have a program which consists of multiple projects in eclipse (working under ubuntu and the projects being in c++), these projects consist of a main executable file, and other shared objects files and static libs.
I want all these projects when built to output their files to one common binary folder, instead of their respective debug folders. This is to make linking easier with the main executable. If there are better solutions please also feel free to share.
Unfortunately, I have found that the C/C++ Build tab does not allow you to set the build location unless you are creating your own makefile.
You've likely found that the Builder Settings tab under Project Properties>C/C++ Build is all grayed out in a default C/C++ project. This is because CDT nominates the internal builder by default for new projects. To change this, you can go to Project Properties>C/C++ Build>Tool Chain Editor and change the Current Builder to Gnu Make Builder. Next, go to Project Properties>C/C++ Build and change the Builder Type to External Builder. You can now opt to create your own makefile for the project, if you like; though I'd recommend leaving CDT to build the makefile automatically for now.
I have the same project requirements of outputting to a /project_path/bin (though I still maintain separation between Debug and Release builds). To do this, I perform a copy operation on the output as a post-build step.
To do this, go to Project Properties>C/C++ Build>Settings and select the Build Steps tab. In the Post-build steps under Command:, enter:
cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "/path/to/bin/directory/";
Obviously replacing the "/path/to/bin/directory/" as required.
I personally prefer to maintain my project files in a workspace/build directory; copying binaries to a workspace/bin directory and libraries to a workspace/lib directory. At first I found this copy workaround to be an inconvenience, but have come to appreciate it because it isolates the interstitial build files from the final binary/library.
For binaries, I would use:
cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "${WorkspaceDirPath}/bin/";
For libraries, I would use:
cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "${WorkspaceDirPath}/lib/";
I include the variable "${BuildArtifactFilePrefix}" because CDT includes "lib" as a default prefix for static libraries, which I actually prefer.
You just need to ensure that the target directory exists before building; Eclipse/CDT will not create the directory for you.
Also, just remember that these copies will be left behind in the /bin or /lib directory on clean, but overwritten on any subsequent rebuild.
Try Project->Properties
Under C/C++ Build->Settings you have a tab called Build Artifact.
Under there you have Artifact name. This defaults as ${ProjName}.
Modify this to specify a relative directory path to where you actually want the final file to end up. So could be ../../lib/${ProjName}
The intermediate files (.o and .d) will still build to the sub-directory (Debug or Release) but I guess it's better off if they are there anyway and it is only the finally built library for which you want to change the build path.
If you find it inconvenient typing the relative path like this, I use Environment to create environment variables with relative paths taking me back to a "root". One of this I have is ${LIBDIR} and this is a relative path from where the project gets built. It is usually used for linking in other libraries, but can also be used as a target. Then you would set Artifact Name to ${LIBDIR}/${ProjName} which works well if you use different directories for debug and release builds.
Go to
Project Properties -> C/C++ Build -> Settings -> (tab) GCC C++ Linker
The command line pattern is shown on the right side
${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX} ${OUTPUT} ${INPUTS}
Put in front of ${OUTPUT}
${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX} ${ProjDirPath}/bin/${OUTPUT} ${INPUTS}
or
${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX} MyMainProject/path/bin/ ${INPUTS}
From https://www.eclipse.org/forums/index.php?t=msg&th=207500&goto=665566&#msg_665566
In my project the build path defaults to the Build Configuration name, so I could use a ${ConfigName} macro to retrieve the build path in a post-build step:
${workspace_loc:/${ProjName}}/${ConfigName}/${BuildArtifactFileName}
Then you can copy target binaries to your common binary folder, or do something other in the build folder of that particular configuration.
If you open up the project's properties, there is a tab C/C++ Build. This has an option for build location, where you can specify the build directory. It seems you could change this for your multiple projects so that they share the same build directory.
Just happened to be working on something that led me down a similar path - so I'll offer it up as an alternate solution/reminder to myself:
In Eclipse (at least in Luna) the generated makefiles are actually rather decent and convenient. I personally like to create several build configurations (Release and Debug variants with 32 and 64 bit architectures), and supplement them with debug and run (F5 and Execute, respectively) configurations.
To continue: I have been toying with packaging on Debian and found - during the act of said toying - that I needed to create and test an install target. Eclipse neither generates for you, nor provides an interface to - a configuration - for customizing or adding an install target; Other than a place where you can specify that another target exists.
So technically Eclipse does provide an interface; kinda. Hence, I stumbled across the makefile.init, makefile.defs, and makefile.targets files.
Process/Workflow:
Create a file makefile.targets in the root directory of your eclipse project; In said file define an install target manually. This - of course - allows you to specify every little detail as you'd like, but with the added benefit of all of the configuration provided by Eclipse already complete and available to you for use with defining the rules for the specified target.
After defining the new target in the makefile.targets file, right click on your project's name or main cpp file in Eclipse's project explorer, and then select Make Targets->Build..., and finally Add to instantiate a pop-up. Alternatively, you could select 'create' in the last step instead of 'build' and it would provide the same pop-up required for the next part. Add the name of your new target and - leaving everything else at their default values - click ok
If you chose to add the new make target by right-clicking in Project Explorer and selecting Make Target->Build..., after adding the new make target you will be brought back to the first pop-up which resulted from selecting Build.... Otherwise, find your way to the Make Targets->Build.. pop-up now. Select the desired target and then click on Build.
Looking through Eclipse's auto-generated makefiles was an excellent way to learn the makefile syntax and overall structure, and get into some advanced usage of includes and conditionals.
Here are some portions of an example makefile, which - at least I hope - will demonstrate manually setting the output directory of a build:
prefix = /usr/local
bindir = $(prefix)/bin
sharedir = $(prefix)/share
mandir = $(sharedir)/man
man1dir = $(mandir)/man1
...
# Typical all target
all: <binaryname>
#Typical clean target
clean:
rm -f <binaryname> <objectname>.o
# Target invokes all, then installs to specified locations
install: all
install <binaryname> $(DESTDIR)$(bindir)
install -m 0644 <objectname>.1 $(DESTDIR)$(man1dir)