-
Notifications
You must be signed in to change notification settings - Fork 140
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
moduleType proposal #10
Comments
This seems like a sensible proposal, the only issue I can see is if people mix diferent types in different files but they'd be in the wrong then. |
Should we have a recommended set of values even though it may not be strictly enforced? |
@wycats first raised this proposal AFAIK +@paul_irish |
Yes, people will usually follow the guidelines, it's good to encourage consistency. |
Yes, we agreed that moduleType would be added at a recent meeting. The original proposal is in this document by @wycats. I have some proposed wording in #13. It could be expanded to take in all of the details of the original if necessary. |
I'm a little worried whether
Sorry, I realize this all sounds really negative -- I'm totally on board with solving the underlying pain, and having the I'm available to chat on Skype too if anybody wants to sync up. Cc @rpflorence |
Yes
Bower needs to be more then an empty sack, it needs some sort of convention/structure that IDEs/tools can rely on for it to be used as a base of a tool chain. |
I think you could say the same thing about the As a build tool author, it seems like the best way to differentiate a CommonJS module, AMD module, ES6 module, and browser global is to build an AST and poke around till you arrive at a best guess. I would much rather have the component author just tell me what I'm working with and how they want it built. As @briandipalma points out, this seems like it's intrinsic to the package and would make my life (as a build tool maintainer) and the author's life easier. |
For the record, I agree we need more than an empty sack for it to be useful -- I'm just not sure if the additional functionality belongs in bower proper, or if we should have bower combined with some other tool. |
It's not really additional functionality, it is purely about allowing a bower package to declare features intrinsic to the package. This is the bower.json spec repo after all, we are not dealing with code. Bower shouldn't couple itself to any specific tool, it should encourage package creators to provide all the package meta-data that any tool/IDE/live development bundler requires to achieve its aims. |
Since this has already been implemented in a release version of Bower itself (bower/bower#934), could at least the as-implemented functionality get promptly added to the spec? |
We are going to need the ability to specify the "main" script (if bower can decide what that means) for each module type. While we can do UMD to support lots of types, you can't support native modules and legacy modules in the same file. For more info, see instructure/ic-ajax#13 |
@rpflorence to an extent I think you're right. But I'm also worried about too much build tool fragmentation. Maybe we need more than a { "name": "jquery",
"main": "jquery.js",
"amd": {
"main": "jquery-amd.js"
},
"es6-module": {
"main": "jquery-es6.js",
"dependencies": { "es6-module-transpiler": "*" }
}
} Each custom subsection could provide overrides for any existing properties. Maybe "dependencies" is a bad idea, I dunno. But I can see other properties besides I feel like I got this idea from anther package manager or format. |
I am +1 on recursive package.json formats where child nodes override parent nodes, then tools can do what they need to do and authors can package how they need to package. |
Wrote up the alternative idea for discussion in #23 |
I think there are two issues at play here
The post by @josh in this thread and #23 touches on both of these concepts by overlaying overrides for different types, much like the Packages/1.1 overlay. However, I feel we are limiting ourselves to an enum of known systems. Instead, we may just want to leave this flexible and have the developer describe n different variants of their bower package for consumption.
Variants describe alternate consumable versions of the package. The sensible defaults would be |
Ping! :) The |
I'm rather new to Bower, so having |
@desandro Could you please close this in light of #13 (comment) ? |
@unscriptable just mentioned this (#7 (comment))
Related to this I believe bower/bower#934
moduleType
would allow the developer to specify if their package is AMD, global, CJS, etc.The text was updated successfully, but these errors were encountered: