+++ This bug was initially created as a clone of Bug #165124 +++
NetBeans has good "Import" feature in java file and "Include" file in php file.
Why not extend it to support javascript .
The worst is that Netbeans 7 does a good job with most toolkits, like Dojo, BUT ONLY IF they are put in the project dir.
I didn't find any way to put Dojo (and the others toolkits) in a root dir, so they can be referenced by many projects without duplicating everything in every project dir.
THAT IS A MUST not only for space problems, but also for maintainability: just imagine I have to do a change in 1 line and I must replicate in 20 projects! :-(
So, a simple way to cope with this HUGE design bug, is the same as Eclipse: an option to specify the paths to dirs, using that option to extend the dirs Netbeans scans to create code completions rules.
I think an expert developer of the Netbeans team can do that in 20 minutes.
Without this option I can't use Netbeans for Javascript projects.
See Also
http://forums.netbeans.org/topic43936.html
PS: I'm not able to start a new bug from scratch so I used the most compatibile to start a new one.

I've done a workaround for linux: making a soft link in the project have the same effect as putting the real dir inside the project.
So, having prj1 with /dojo and prj2 with a php project, adding a link in prj2 such as ln -fs ../prj1/dojo, solev the problem.
The same trick doesn't apply to windows: netbeans ignores windows links.

Most commonly I would use vendor branch [1]. Therefore I see no advantage in proposed change. Actually proposal is quite close to bad practice. I do understand that in real life one cannot always use vendor branches but nevertheless the NetBeans IDE should not encourage such practice.
Further on, I don't see why is this bug marked as P1. [2] At best priority can be P3. There are way much more important issues then this one.
[1] http://svnbook.red-bean.com/en/1.1/ch07s05.html
[2] http://wiki.netbeans.org/BugPriorityGuidelines

>Actually proposal is quite close to bad practice.
Let people decide on it. This is the first time I face a product that force to have library INSIDE the project itself.
Vendor branch can be a "solution" for some cases, but not for all cases and anyway is very bad supported in Netbeans because is certainly not a good choice to degenerate, in unnatural manner, the Netbeans Project using it as a multiproject container.
Netbeans is clearly designed to have 1 folder for 1 project (that's shown by the option that relate 1 project to another).
So, the right way (used also from Eclipse, Visual Studio, and any other IDE of the universe) is
/dojoroot
/Proj1
/Proj2
/Proj3
not
/ProjVendor
/ProjVendor/dojoroot
/ProjVendor/SubProj1
/ProjVendor/SubProj2
/ProjVendor/SubProj3
The 2nd way I suppose will also introduce a great overhead in the IDE, in that Netbeans scans everything, and also show everything in the code completion, even what I don't have to see.
Just imagine 10 projects: 2 use dojo, 2 jquery, 2 dojo + jquery, 2 YUI + jquery:
With vendor branch I should have
/ProjVendor1
/ProjVendor1/dojoroot
/ProjVendor1/SubProj1
/ProjVendor1/SubProj2
/ProjVendor2
/ProjVendor2/jquery
/ProjVendor2/SubProj2
/ProjVendor2/SubProj3
/ProjVendor3
/ProjVendor3/jquery
/ProjVendor3/dojoroot
/ProjVendor3/SubProj4
/ProjVendor3/SubProj5
/ProjVendor4
/ProjVendor4/jquery
/ProjVendor4/YUI
/ProjVendor4/SubProj6
/ProjVendor4/SubProj7
having to maintain 2 dojoroot and 3 jquery even if are all the same versions.
Then, when SubProj1 have to use jQuery, I have to move it under ProjVendor2.
The same under Eclipse (or even Netbeans if used with something other than JS!) would be a more simpler:
/jquery
/dojoroot
/YUI
/proj1
/proj2
/proj3
/proj4
/proj5
/proj6
/proj7
/proj8
and every project use what it wants when it needs.
That's why Vendor branch is not a panacea, and that's confirmed by Netbeans itself since it don't force to use it under PHP, JAVA, C++, and so on. Only Ajax developers has to face this BUG and P1 is a good choice for a design ERROR.

Hello,
I have been using this feature in Eclipse for the past years and it works realy well there.
I realy like Netbeans handling of different scopes and objects way ahead of Eclipse but this missing feature realy anoys me.
I do server side JS dev and I have a set of libraries that I use, I don't want to copy them one by one in my project, I have no interest in jQuest ExtJS and so on.
With this feature Netbeans can turn into a true IDE for Javascript which start to be a very common language for server side stuff as well with NodeJS and other stuff.
Thanks,

Title of this issue is a bit misleading - I would rename if to "Add support for JavaScript global library manager", but ... there is already such bug reports
"javascript framework support" (2010-12-27 22:30 UTC by Flyingmana@netbeans.org)
https://netbeans.org/bugzilla/show_bug.cgi?id=193855
Add support for libraries. (Reported: 2007-11-19 10:47 UTC by Jan Jancura)
https://netbeans.org/bugzilla/show_bug.cgi?id=122265
This thread looks to be the most recent one, so here is my use-case ...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I have my own JavaScript library and it is developed in context of one MAVEN project. That MAVEN project is included into multi-module MAVEN project which collects resources (JavaScript files as well) from multiple modules into single place at runtime. Having this in mind, I'd like to have support for shared code completion for JS across all these projects. I would say that following will work for me ...
1. Explicit referencing of required global JavaScript files somewhere in Tools->JavaScript Libraries or Tools->Options->Editor->Code Completion->JavaScript
2. Having an option for JavaScript editor to share Code Completion/Intellisense information extracted from JavaScript files (all ones assigned to text/javascript MIME type in Tools->Options->Miscelaneous->Files) in All currently open projects or Currently open javascript files (even if they are not included into any project).
Having both options available in parallel would be excelent.