Proposed directory layout for third party code

[gseguin]

I propose that we relocate the "third-party" code the following way:

vendors
    |-- jquery
    |    \-- jquery.js
    |-- jquery-plugins
    |    \-- jquery.hashchange.js
    |-- jquery-ui
    |    |-- jquery.ui.core.js
    |    |-- jquery.ui.widget.js
    |    \-- jquery.ui.tabs.js
    |-- qunit
    |    |-- qunit.js
    |    \-- qunit.css
    |-- requirejs
    |    \-- requirejs.js
    \-- requirejs-plugins
         |-- json.js
         \-- text.js

[gseguin]

@scottgonzalez, @arschmitz: feedback?

[scottgonzalez]

The treatment of plugins as a special grouping seems odd to me, but I really don't want to get into a long debate about how to organize third party code since every project seems to be doing different things.

I'd just make sure there's a plan in place for how download builder is going to handle third party dependencies.

[arschmitz]

we want to make sure what ever we use for structure matches what ui is going to use for builder compat as that is a current priority. Also if we are going to manage with bower wont we end up with all the files from the repo not just the ones we want? ( ex all of ui ). also if there a reason you chose vendors over external ( just ask because we have external already and so does ui )

All that said i dont really care much as long as we match what ui does

[gseguin]

Agreed, requirejs-plugins can become requirejs/plugins.

@rxaviers can you comment on how that would work with the download builder and
counter propose if this is not going to work?

Ghislain

On Thu, Jan 9, 2014 at 1:46 AM, Scott González notifications@github.comwrote:

The treatment of plugins as a special grouping seems odd to me, but I
really don't want to get into a long debate about how to organize third
party code since every project seems to be doing different things.

I'd just make sure there's a plan in place for how download builder is
going to handle third party dependencies.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6871#issuecomment-31912231
.

[gseguin]

vendor
    |-- jquery
    |    \-- jquery.js
    |-- jquery-plugins
    |    \-- jquery.hashchange.js
    |-- jquery-ui
    |    |-- jquery.ui.core.js
    |    |-- jquery.ui.widget.js
    |    \-- jquery.ui.tabs.js
    |-- qunit
    |    |-- qunit.js
    |    \-- qunit.css
    \-- requirejs
         |-- plugins
         |    |-- json.js
         |    \-- text.js
         \-- requirejs.js

[gseguin]

As far as the third-party directory name I chose vendor for no good
reason other than noticing it was used by a few other projects as their
third-party directory. I don't have a strong opinion on this so both names
are fine with me.

Ghislain

On Thu, Jan 9, 2014 at 10:16 AM, Ghislain Séguin ghislain@gmail.com wrote:

Agreed, requirejs-plugins can become requirejs/plugins.

@rxaviers can you comment on how that would work with the download and
counter propose if this is not going to work?

Ghislain

On Thu, Jan 9, 2014 at 1:46 AM, Scott González notifications@github.comwrote:

The treatment of plugins as a special grouping seems odd to me, but I
really don't want to get into a long debate about how to organize third
party code since every project seems to be doing different things.

I'd just make sure there's a plan in place for how download builder is
going to handle third party dependencies.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6871#issuecomment-31912231
.

[rxaviers]

We'll need to export the require.js config paths for the dependencies (not devDependencies), similar to the current js/requirejs.config.js content, but JSON only, eg:

{
  paths: {
    "jquery": "vendor/jquery/jquery",
    "jquery-ui": "vendor/jquery-ui",
    "text": "vendor/requirejs/plugins/text",
    "json": "vendor/requirejs/plugins/json",
    "depend": "..."
  }
}

This could be exported as a manifest file, or inside an existing file, eg: packages.json or bower.json? Thoughts?

[rxaviers]

Actually, we'll need to export the require.js config, including shims.