Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for new combined paths/packages config format #235

Open
unscriptable opened this issue Oct 16, 2013 · 5 comments
Open

Proposal for new combined paths/packages config format #235

unscriptable opened this issue Oct 16, 2013 · 5 comments
Labels

Comments

@unscriptable
Copy link
Member

We've been thinking that the paths and packages configuration syntax is bulky. It's also not clear to new devs which to use: paths or packages?

This new syntax would make it succint to declare the two most common types of packages: those like when.js and those like jquery:

packages: { 

    // a typical package wherein the ancillary modules 
    // are siblings to the main module
    when: 'packages/when/when',

    // a typical mega-module-just-wrapped-in-amd package
    jquery: 'packages/jquery1.9.1/jquery.min',

    // a package whose modules are in a sub folder
    funky: {
        main: 'packages/funky3.1/funky',
        modules: './lib'
    },

    // back-compat with current syntax
    wire: {
        location: 'packages/wire',
        main: 'wire'
    }
}

We could offer the back-compat syntax by sniffing for the existence of location.

Thoughts?

@gehan
Copy link
Contributor

gehan commented Nov 8, 2013

That looks great @unscriptable, would make things a lot simpler. Would making declaring jQuery, poly, curl packages a lot cleaner

I assume you could still used paths if you wanted to?

@unscriptable
Copy link
Member Author

I was hoping we remove paths. I guess we should keep it for cross-loader compat and back compat. :)

@briancavalier
Copy link
Member

Yeah, cross/back-compat seems like the only good reason to keep it, imho.

@gehan
Copy link
Contributor

gehan commented Nov 11, 2013

I wouldn't use it now! However it's standard with other libs I assume

@teehemkay
Copy link

Nice!

+1 on the simplified packages syntax.
+1 on keeping paths for 'for cross-loader compat and back compat' :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants