-
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
Spec main hash extension mapping #7
Conversation
I endorse this internet e-note |
This is one of the most thought out arguments we've had to date. |
👍 really just clarifying what it actually is.
Nah, Bower can just pluck the first JS file.
If we were to go for extension mapping, an array would be better. Making it verbose just to make it clear isn't worth it. Bower can easily pluck the extensions and categorize them. Bower can also prevent publishing with multiple of the same extension. |
Independent of this PR, #8 attempts to clarify the alias intent.
Right, for "list". But that behavior doesn't seem ideal.
Ha, well I'd rather not deprecate it then, #6.
The other thing thats strange about using an Array is order. |
One feature of using an object rather than an array is that you could specify both the css source and the minified source.
Not sure if this is useful as it could be argued that minification is the job of the build tool and it kind of fudges the definition of a file extension. I'm +1 for the Object as I think it will make it more flexible for the future however I don't think the key should be strictly defined as the file extension as without this restriction it could be useful for extensions to do something like:
|
I kinda like the min example. Neat idea. I think so long as "{package}.{key}" maps to "{package}/{value}" it should be okay.
|
@danielchatfield updated with your suggestion. I'm having trouble with succinct wording for multiple file extensions. Let me know if you come up with anything clearer. I'm considering using this for source maps in Sprockets. If a main provides "main": {
"js": "foo.js",
"min.js": "foo.min.js",
"coffee": "foo.coffee"
} Here most build tools may just default to using "main": {
"js": "foo.js",
"min.js": "foo.min.js",
"dart": "foo.dart"
"js.map": "foo.js.map"
} Or here, the author used Dart and compiled to js. Sprockets doesn't understand dart, but it sees there a map already checked into source. Sprockets would then use the existing map and link it to the original dart source. |
Looks good 👍 |
Related, #9 |
I'm not sure if this the appropriate place to discuss this, but we also have different flavors of JavaScript: global scripts, AMD modules, CommonJS modules, and ES6 modules. At one point in a discussion thread (can't find it, atm :( ), there was a proposal for a This information is important to loaders and build tools. Any idea how this would fit into this proposed strategy? The discussion about having different keys for minified css sounds similar to having multiple script/module formats. |
@unscriptable definitely open a new issue on this repository. Lets discuss. |
@sindresorhus Verbosity should not be the main priority especially if IDEs/tools auto generate bower config files. This proposal along with the |
Neither |
I don't understand how an object is compromising and an array is not. Surely |
The array confused people now into thinking that its basically "files" and you can do stuff like: "main": ["foo.js", "bar.js"] Theres no way to represent that file list as "main": {
"js": "foo.js",
"js": "bar.js"
} |
and theres no rationale to, either, right? |
Nope. |
This may not be the best place for this comment and admittedly I have not been a part of this discussion or the development of Bower at all, but having used it for a while and really loving it, I do want to offer my opinion. My main issue with Bower is there is no way to easily know what files I need to include to actually use the package as a dependency in my application. I currently manually maintain a component map that maps each component to a set of files needed to include the dependency. The current description of Here is an example of what I propose.
Firstly, rename As an everyday user of Bower, this would be lovely. Either way, many thanks for all the amazing work on such a helpful tool. |
@zzolo I may be misunderstanding
I'm not sure that's what For instance, if your package consists of JS code broken up into several files you would specify a JS file that inside it may have Does this make sense? |
@briandipalma That does make sense. But...
|
|
There are a few libraries out there that specify a directory in @wibblymat is a directory in your |
@robdodson I've just asked for clarification on that: #19 |
That sounds a great. But I would like to throw in some more exotic examples, because most debate is about JavaScript/CoffeeScript and CSS/Less/Sass, but I would to use Bower for all my front-end resources. So lets say I want modularize my HTML templates to reuse them across multiple projects. This is okay for a single HTML template:
That is nice. I can now import my
And now I can use Another very use case - which I really don't know if it extremely exotic_ or maybe not so uncommon as I think: multiple sources as used in
It could be used like this:
(Note. The wiredep'esk annotations to get Bower dependencies...) And my build tool could resolve this to:
Maybe this solution is not the most beautiful. I just want to push the discussion more to HTML and other assets. |
@donaldpipowitch see #9. |
Is "paths" official now? |
@donaldpipowitch Nope, the Bower spec just continues to languish; see #6 (comment) |
Oh :( This is quite sad. |
@donaldpipowitch Take a look at http://jspm.io/ |
JSPM is for JavaScript resources only, right? I always looked at Bower as a package manager for all frontend resources - even fonts and images. |
@donaldpipowitch It's a package manager, there are plugins for SystemJS (ES6/CJS/AMD/global module loader it uses) for CSS, text, images etc. What's in the package doesn't matter to either npm, bower or jspm. |
Thanks. I'll look into it again. But it isn't really widely adopted or has this changed? |
It's quite small at the moment but I think bower is moribund and frankly I don't think jspm constrains you too much. Your code will still be ES6 modules or CJS and installable by any other package manager. |
If the main array is to be deprecated #6, I need a replacement for it.
The confusion of the main array comes from the fact that you should only have one type per extension in the array. Making an explicit map of extension to filename reduces the possibility of invalid main definitions.
extensions not types
I think “extensions” make more sense over “types” (script, style, font). For one, we’d have to spec all the the types. Bower is about all assets, not about one specific type and the ones we can think of. Maybe you want to package to contain text or data files. We shouldn’t stop you because it doesn’t fit inside a predefined bucket.
main
is just a path alias.Means alias
foo.js
tofoo/scripts/bar.js
andfoo.css
tofoo/scripts/bar.css
.Extensions express capabilities to build tools. Some tools can’t handle files that will processing. Require.js for an example will never know what to do with a .coffee file. It needs .js files. It makes sense for it to just use the file of package[‘main’][‘js’]. Other tools like Sprockets are aware of both .css, .scss, .less, etc and can choose the based on which preprocessor the user has available.
Seems acceptable to me. Coffeescript aware tools can prefer building from source, while other tools may just pick the compiled version and be fine. This helps Sprocket’s automatic source map generation.