"main" vs "files" vs "ignore"

[eurosat7]

HI!

Due to

bower/spec#43
and
bower/spec#47 #Proposal 1: files flat list

I would like to use "files" and/or "ignore" in addition to "main" in the bower.json of required packages to find my assets.

Just an example:

    var bowerfiles = require('bower-files')({
        'include':['main','files'],
        'exclude':['ignore']
    });

And/Or:

    bowerfiles.include("main").include("files")
    bowerfiles.all().exclude("ignore").exclude("main").ext("js").files

What do you think?

[ksmithut]

I'm still trying to do an in depth read of it, but is it like the 'files' in package.json? If so, the files array is just a list of files that need to be published in the tarbal that gets stored in the npm registry, as with the ignore option. AFAIK, bower links to github and doesn't actually manage the storage of the versioned packages, but I could be wrong. In that case, maybe files and ignore have special meaning that has no relation to how package.json works.

By the looks of some of these issues, I might be able to dramatically reduce the amount of code by leveraging more of the core bower package. It's been a while since I've looked at any of their new stuff. It shouldn't be hard to support this if the bower list command supports them.

[eurosat7]

That was a quick reply. ;)

Here some more indepth:

We use svn.
So far we were happy using composer and a satis with private repositories for your php needs.

Now we want to manage our own assets/skins/themes in separate packages. And also use external packages like jquery, modernizr and many more via bower.

We have repositories managed via "private bower" as our private "packagist" replacement.

We do not really "publish" versions in tar balls. Instead we work on dev-branches and include them where needed in different projects still in developement. Some are even linked as svn externals.

So now we try to find a way to get out theme-packages and its dependencies compiled (less) and combined and all images inside the css files into the "right" place.

bower no longer likes globbing in "main".

[ksmithut]

makes sense. Taking a look at the bower list command, it should be pretty easy to support with with some refactoring. I'll work this weekend to add those as features.

[eurosat7]

I owe you a pizza. :)

Side note:
Here is a way we could "solve" the problem but that feels totally off:

var globmain = [
    "**js/**.js",
    "**css/**.css",
    "**other/**.assets",
    "**img/**.{png|gif|jpg|svg}"
];
var bowerfiles = require('bower-files')({
    "overrides": {
        "our-package-1": {
            "main": globmain
        },
        [...],
        "our-package-719": {
            "main": globmain
        }
    }
});

[ksmithut]

ya, including "files" as an option would feel much cleaner. too many stars :)

[ksmithut]

@eurosat7 Just an update, still looking into a clean solution. The bower list command is async, which would dramatically reduce the usability of this module. I'm going to dig into the internals of that command and see if I can replicate it with a sync version.

[eurosat7]

Here was what I am up to [link deleted].

side note: I am also trying to follow composer require definitions as we run a mixed setup.

[ksmithut]

Sweet :) If you can get that in a PR that would work with this version, that'd be great :) It's been a while since I've touched this code and my javascript style and libraries of choice have changed a lot. I'm considering a refactor with breaking changes, but I'd like to get this feature in before that.

[eurosat7]

I am not allowed to code for PR at work.

But please(!) : Feel free to rewrite and/or comment/document.
And the less dependencies you have the better. ;-)
And the easier the code is to follow the better. Some parts of the code felt uneasy.

[ksmithut]

Ya, there's a lot I don't like about they way I did this. I'm going to take a more functional approach in the future.

Oh man, that's a rough work rule. Working for a company that leverages open source but isn't willing to contribute back always feels like bad mojo.

I'll work on the refactor and try to get this in as soon as possible. Sorry for the delay!

[eurosat7]

Feel free to contact me via mail.

[ksmithut]

@eurosat7 Have you tried using wiredep? I'm beginning to think they're way ahead of the game as far as dependency resolving goes. Pretty clean codebase, and lots more updated than mine. They seem to be more spec compliant than me, and they seem to always be on the radar with the bower team.

[eurosat7]

I might try wiredep or webpack in the next project. I looked at them some weeks ago and like their approaches. But for now legacy stuff is hindering me and I had to create an individual solution.

Feel free to reject and close this issue if you think it's not part of this package after having a closer look.
Thanks for your time. :)

[ksmithut]

No, I still plan on adding this feature. It's just that the more I read about this "files" thing, the more I'm saddened that I didn't keep up. It sounds like they kind of stepped away from the "main" property as the canonical source of having a list of files. Although, even if I had kept up, I doubt that all bower packages would have updated accordingly. I'll work on this today

[ksmithut]

@eurosat7 I have a pull request in that I'm planning on modifying based on your feedback.

#70

Basically, I added an option .useFiles() that will opt to use the files property instead of the main property. If the "files" property isn't present, it will use the "main" property. I still don't feel super good about it, but if this would work for your case, I'll merge it in a publish a new version. I really don't like the way I've organized my code and I'd like to rewrite it using a more functional approach and is more in line with the bower spec. Let me know what you think of what the behavior should be (with fallbacks and such).