search

duojs / duo

A next-generation package manager for the front-end
3.42k stars 117 forks source link

Parse `bower.json` to get main file besides `component.json` #243

Open mgonto opened 10 years ago

mgonto commented 10 years ago

There are a lot of projects that have the bower.json but not the component.json. When using bower, the main file pointer from the config is always a self functional JS file. It's not like the main from package.json which does have requires as it's parsed by browserify.

Therefore, I'd suggest parsing the bower.json to get the main file if component.json isn't available.

This issue is created from a conversation in issue https://github.com/duojs/duo/issues/238#issuecomment-53111825

Thanks!

stephenmathieson commented 10 years ago

hmm idk about this... what about bower packages that don't support common js? for example: twbs/bootstrap. what would require('twbs/bootstrap') return?

also, what about bower.json files without .main?

mgonto commented 10 years ago

Regarding bower.json files without main, we'd just ignore them I think. It's like there's no bower.json. Having that into account, there's another angular official repo for example that does have a main. check this out

Regarding those packages that don't support common js, that's a tougher call :). There's no way of knowing without parsing the file. For those cases, I think the ball is in the user's court. If he includes a dependency that doesn't support common js, he'll get null or undefined in the require or an error. And it's his fault that he used it for those cases. But that's the only case that wouldn't work. It does make sense to support it for all the other cases I think.

@stephenmathieson what do you think?

stephenmathieson commented 10 years ago

imo, it brings along a lot of gotchas. if support were to be added, we'd need a lot of documentation explaining when bower package is supported, as i'm sure people would try to require('some-user/some-package-without-exports').

mgonto commented 10 years ago

It does bring some gotchas and it does need lots of documentation, but it adds lots of bower packages that do have common js into the duo loop without a hassle. IMHO, it's a good trade off, since it makes it really easy to add new packages.

wilmoore commented 10 years ago

we'd need a lot of documentation explaining when bower package is supported, as i'm sure people would try to require('some-user/some-package-without-exports').

This doesn't work perfectly as-is. For example, there are plenty of bower packages that I've tried over the last day that didn't work at all. That's fine, some things just won't work, but I think, making the tool smarter can only help to make the user experience better -- in the cases where it does work, it is pretty sweet.

mgonto commented 10 years ago

I agree with @wilmoore. Also, each day there's more people doing packages that support common js

nickjackson commented 10 years ago

On the back of the commonjs problem, I'm wondering if there is a nice way of exposing the globals in packages that don't module.exports and having them accessible by require().

This functionality may be better suited as a duo plugin.

stresslimit commented 10 years ago

+1 for this.

Like it or not, bower is the big player here, and supporting some basic bower stuff out of the box would be a big plus for duo taking off [which is not guaranteed right now to be honest]. Frankly, to read bower.json for "main" would be easy to implement and provide a lot of value for a lot of people. And if parsing runs into any inconsistencies/impossibilities [lack of "main"] it can stop being magic and make you do the work again. And of course give you a nice error message "this repo doesn't support commonJS: ... lack of module.exports [or whatever the error]". Then presenting the user with the maintainer's email address to request :)

Manually going through to add specific file path is lame when projects have already added the metadata to bower.json.

frankwallis commented 9 years ago

I have created a plugin duo-debower which converts the bower.json to a component.json so you can require the module. It also converts the dependencies in bower.json to their github urls in component.json using bower lookup.

It's not quite usable yet as it needs duo to expose a hook which runs immediately after the package is fetched from github (https://github.com/duojs/duo/issues/291).

matthewmueller commented 9 years ago

@frankwallis nice! yah we need to get the hooks going. just no time :-(