659109 - Allow nested dependencies

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect)

Description

[Sean McArthur [:seanmonstar]]

An example (on Builder) of what a user should be able to expect to work just fine:

He wants to make an Addon, and wants to require 2 packages, Ender, and Twitter. Ender has it's own klass dependency. Twitter also has it's own, separate klass dependency. Since Twitter can (and should) do `require('klass/klass')`, that will conflict with Ender's klass (and vice versa).

Ideally, each package could have it's own dependencies directory that will be checked first, even using the PACKAGENAME resolution.

Expected:
lib/
dependencies/
    twitter/
        lib/
        dependencies/
            klass/
                lib/
                    klass.js
                    klass-util.js
    ender/
        dependencies/
            klass/
                lib/
                    klass.js
                    ender-bridge.js

Some conversation with Brian about the current module and package resolver: http://etherpad.mozilla.org:9000/sdk-dependencies

Comment 1

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

This is more or less similar to what is being used by nodejs and has another nasty issue of inability of sharing dependencies. So for example if your lib passes objects produced by ender to the twitter which does something like:

if (object instanceof klass.Foo) // do something

there is no way to satisfy this condition even if they both depend on the same klass.js

This is very simplified example of an issue.

Comment 2

[Sean McArthur [:seanmonstar]]

(In reply to comment #1)
> if (object instanceof klass.Foo) // do something
> 
> there is no way to satisfy this condition even if they both depend on the
> same klass.js

This is true. At least from Builder's point of view, we _know_ when a Package in different dependencies is the exact same package, since they are identified by id and version number. Thus, at least in Builder's case, pull those dependencies to top level, and not have a duplicate, thus both packages will be able to access the same klass.js.

For the CLI, users could do that step themselves manually, since they have access to the file system?

Comment 3

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

In nodejs they have `node_modules` which is equivalent of `dependencies` proposed here. They way they solve this is by putting shared dependency to the `node_modules` in the lowes upper level. Unfortunately that complicates module search logic, they basically look into node_modules of each folder until they reach package root. Our search module search logic is already much complicate then nodejs's: https://github.com/mozilla/addon-sdk/blob/master/static-files/md/dev-guide/addon-development/module-search.md

This will make it even more complicated, but yes that's a possibility. Also please note that node has `npm` that handles all this for users, doing it manually would be just overkill IMO.

Also I know addon builder would handle this, but I think it's primary users are casual devs that will less likely write libs with complicated dependency graphs, hard core hackers on vim / emacs and alike are the ones that will most likely run into this and they won't switch to addon builder at least yet.

Comment 4

[Daniel Buchner [:dbuc]]

I fully agree that the target Builder users will be less advanced than those who are likely to create complex libraries with complicated dependency graphs.

On the other hand we are left with the question of how best to surface the contributions of advanced devs to the community, specifically to those who use the Builder. While it is important to make a distinction between advanced devs and those who would use the Builder, we shouldn't create two silos where advanced stuff is unavailable to Builder users.

This is the question we'll all need to explore in the coming months. It may mean we accommodate such advanced cases in the Builder/SDK at a future point to give our less advanced users a way to utilize the great things our advanced users produce, know what I mean?

Comment 5

[Sean McArthur [:seanmonstar]]

As Daniel said, this isn't needed immediately. 

However, as he said, once the advanced developers start to make complicated libraries, and wish to share them with the casual developers to just include and hope it "just works", we would need to easily allow the upload on libraries with complex dependency graphs.

Comment 6

[Myk Melez [:myk] [@mykmelez]]

P1 for determining whether or not to do this; if we decide to do it, we'll have to retriage to determine its relative importance.

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(Pushing all open bugs to the --- milestone for the new triage system)

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(In reply to Myk Melez [:myk] from comment #6)
> P1 for determining whether or not to do this; if we decide to do it, we'll
> have to retriage to determine its relative importance.

Re-adding the triage flag because 5 months have passed without any activity in this bug.

Comment 9

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

In a future SDK where there is no packages it's less relevant. That being said we will support node like semantics for nested dependencies.