Is there a way to configure Webstorm so that when it refactors, it ignores specific areas of my project. Specifically, I would like to be able to ignore folders containing 3rd party dependencies and built assets, such as node_modules.
You can make a JavaScript library of these folders as described here. They will be excluded from renaming and other refactorings scope.
You can also mark directories as completely ignored - they will then not show up in Webstorm's project view, will not be included in searches, won't be scanned when refactoring, etc. This is typically useful for directories containing built assets.
Right click on the folder in the project view, and choose "Mark Directory As", then select "Ignored".
Related
Below is a picture I grabbed off google, and it is actually linked back to a previous Stackoverflow question.
So, on the left (project explorer view) we see an Includes and src directory. I believe the Includes really is just paths to where header files may reside in the file system.
So now for my question, should header files I have made say "xyz.h" reside in the src folder in an Eclipse project?
Currently I put them somewhere in the file system on my Linux machine and then path to them (so they show up in the "Includes" for the project), this allows me to edit them in the eclipse editor and so forth, but I believe they are not actually a part of the "Eclipse project".
Not sure there is a right and wrong answer, just looking for what others few as the "best" way.
Generally the header files that you create should be in your project.
The main purpose of the "Includes" mechanism is finding the headers of third-party libraries that your project may use.
You can also use it to specify the location of includes inside your project. For example, you might have an include folder inside your project, put all (or some) of your headers there, and configure that as an include path. Eclipse allows you to configure include paths relative to the project, by choosing "Project Path" when adding the include in the project's Paths and Symbols preference page.
As your projects get large, you may eventually want to split them up into several projects, such as an application and supporting libraries. In a case like that, the application's project would have include paths pointing to the headers in the library projects.
What is the purpose of "Linked" Files in visual studio, and when I would use them versus simply including the class project that contains the file to my current project.
Project + Add Existing Item, arrow on the Add button, select "Add as Link".
Visual Studio strongly favors copying the item you select in this dialog into your project directory. This will keep you out of trouble, like accidentally modifying a source code file or resource that's also used in another project. Or forgetting to check-in the file into source control, by far the most dangerous mishap. Something you'll discover only a year or more from now, far too late to do anything about it.
The Add as Link option overrides that behavior, the file stays in its original location and the project file records the relative path of the file.
Good reasons to use this feature are very hard to come by. Trying to come up with some:
You may want to maintain a single source code file that's included in multiple projects, using Add as Link ensures you'll only ever edit that one single source file.
You may have a project that uses the same source code files as another project but with very different build settings, in which case you'd make all of the project items a link.
You may have a humongous resource that you don't want to have copied repeatedly in multiple projects
You may have a deployable item, like an unmanaged DLL, that you keep in a single directory but is used in multiple unrelated projects.
Digging yourself a deep source control hole is a high risk, be sure to think this through before you commit to using the feature.
Linked files are for when you want the code to be included in that project assembly.
"Wow Jimmy, thanks for pointing out the obvious. But why would I want to do this?"
Well, there can be several reasons, but for now I'll just list one example. Consider the scenario that your company|team requires every assembly to have certain constants or assembly attributes defined. Instead of creating a duplicate class in every single project, you could just have one copy of the file and link it into each project. Update the file once, and every assembly gets the changes.
I'd like to include some folders of static files shared between many projects and solutions.
These files could be images, script libraries or css that are shared between many projects.
I do not want to copy each time the folder inside the project structure but reference it just as we can link files between projects in the same solution so if any file changes in the referenced folder all the projects that link to it will have an updated version.
I know I can put it in a shared dll and embed resouces in it but I'd like to be able to choose witch folder to include.
Is this possible with Vs2010 or Vs11?
Sure, its possible, and not even that hard. Put the files in a well-known location in your hard drive, then add them to each project as a link. See the second section in the following article:
http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx
If you use source control, I would strongly encourage you to have at least one separate folder per solution file, and nest the folder under your solution root somewhere. TFS, in particular, gets antsy if your solution file includes locations that are outside the current workspace. (It will work but you may get strange warnings or errors, particularly if someone else tries to get the solution for the first time.)
Whenever I am adding some files to my project by dragging and dropping in Xcode, a popup message is shown "Copy items into destination's group folder (if needed)".
I noticed that when we are using most of the third party library's we DON'T tick the checkbox and instead specify the library path in "Header Search Path/Library search Path". But for smaller resource files like images, we tick the checkbox.
Which specific scenarios do I have to tick and what difference will it make?
It all depends on how you want to organize you project. It's far more common to store 3rd party frameworks somewhere on your machine that is independent of any project that may use that framework, thus allowing multiple projects to reference the same shared framework project from a standard directory. In that case, you don't want the 3rd party framework copied into your own project, and so you don't check that box.
Images and other resource files are typically owned on a project-by-project basis, so it makes the most sense to store those in the directory of the project itself. To pull that off, you check that box to make sure a copy is made in the project's directory if one doesn't already exist.
Neither of those rules are absolute, you could copy an entire framework into your project's directory if you want, and you could reference media assets from some standard location. It's all up to you to implement good project organization.
Typically, your project is saved to a project folder. If you drag stuff from outside the folder into your project without copying, only references to the added files are stored. You will have to be careful not to delete them, or your project will break.
Also, if you are using version control, such as the built-in git, files not in the main folder will not get added to your version tree.
I got into the habit of copying everything I need into the main folder and then drag-add without copying. This is working well for me and has so far avoided any errors.
Like many people, I would love to have Xcode use a folder structure that mirrors the folder-structure on disk. However, I cannot get the code in "folder references" (the cyan folders) to show up in my project targets under "Compile Sources." Is there any way to do this?
I have managed to even add a cyan folder to the "Compile Sources" build phase, but that does not result in the contents of that folder being added.
How can I use folder references for code?
The simple (and very unfortunate) answer is that Folder References under Xcode remain broken and buggy, they don't work. Tested 04-Mar-2017 in Xcode 8.2.1
Below is an example exploration so you do not have to waste your time replicating the Xcode failure.
(incidentally buggy Xcode crashed twice while I was producing this example)
Per the question, the overall desire is to use a folder reference in Xcode so Xcode picks up all the files in the folder and includes them in the project, and by proxy will update automatically based upon any Finder or Xcode changes of the folder. In this way 50 projects all leveraging the same set of common source code files do not have to be individually updated when those folders get changed. Below explores how this is broken in Xcode (tested in 8.2.1)
The example: ViewController.m includes NSError+Core.h so we want everything from the folder "NSError+Core" to be added to the project.
NSError+Core.h is in this centrally located development folder
Drag the source folder from the Finder into the Project under the "Support" group (nothing up my sleeves, simple drag)
Xcode dutifully offers to add the drag to the target, note the "Create folder references" is selected, not "Create group references". Note also it is clear that Xcode is offering and is told to add this folder and files to the targets.
Although everything looks like it should work, the compiler does not pick up the header file and a recompile yields the same results... can't find header. Ditching the DerivedData does not help either.
So doing a double check, we check the "Compile Sources" under the project and sure enough, the source file is not there either. Remember, Xcode 'added' it to the target...
So what if we drag it from the folder into the "Support" group...
It offers to add them to the project again?! Note that the settings are identical to the first time they were drug in by virtue of the parent folder drag instead of files...
And now the source file shows up in the "Compile Sources" list. Note the bizarre double listing of the files in the project.
(Xcode crashed shortly after snapping this screen shot)
And of course the compiler can now find the header file and the error clears on the import as it should have the first time we drug it in...
Did it just need a little help to "find" the file? If so, the "Create folder references" does exactly what?
So we try and tidy up and drag the files back from the parent "Supporting Files" group to their rightful folder. Without any confirmation, indication, notification, the files just vanish from the group and nothing happens in the NSError+Core folder.
Oh by the way, it really did delete them from the project too... The Compile Sources no longer has the NSError+Core.m reference.
SO to sum up, "Folder references" as implemented thus far do not seem to have any useful purpose... It would appear to be a 6+ year old dunsel on the USS Xcode.
Kevin - linked source folders, folder references, etc, are super useful for when you have a common code base shared across different IDEs, like I do for my games that I compile on Windows, Mac, iOS, Android, Linux, etc. I have 3 different IDEs all building the same shared codebase, so it's very helpful when one automatically picks up on a new file and adds it right into the project after I merely run svn update, and I svn commit from one IDE (say XCode) and my Eclipse in Windows project picks up the change. I have a different project for each because each IDE likes the project files in a certain configuration so it's easier for me to have multiple SVN directories (base-project, project-ios, project-android) that all share code in base-project than to have one mega project directory with the different IDE bits unhappily all shoved into subdirectories (which is what I tried the first time around).
Furthermore - it used to work fine in XCode 3. They seemed to not like that useful of a feature so it is no longer working in XCode 4 as I've just found out.
I just tried doing this to share code across multiple Xcode projects, and our team came to the conclusion that it's better to create an Xcode project that contains all of your shared classes, compiles them into a static/dynamic library, and then add that as a subproject to those that need the shared code. Then you can set up target dependencies and link your shared library. This will get you the "automatic updating" every time you add a new class to the shared library project.
This approach also works well with submodules or even cocoapods/carthage.
You can't. Why are you even trying? A folder reference's job is to embody a folder, without having entries for all the individual files in the folder. It's primary use is for copying an entire folder of resources verbatim into a project. If you want to compile the sources though, then those sources must be referenced in the Compile Sources build phase of the target, which requires having individual entries for each file.
Depending on what's in the folder, it might make more sense to have a Makefile or some other external build process that builds the content in the folder into a static library. This way you can invoke that build process from a Shell Script Phase, and then just link in the resulting static library. Alternatively if you're using this folder as a way to have a shared bit of code (e.g. an svn:externals or git submodule), you could give that folder its own Xcode project and then embed that project into any of your other projects which share this folder.