Default the Component Directory to Resources/public?

[RobLoach]

Resources/public is what Symfony users for any public-facing files.

[pkruithof]

I would use the web folder instead, similar to the assets:install command. Besides, Resources/public is ambiguous when you have more than one bundle.

[RobLoach]

I defaulted the directory to components as that's what both Bower and Component use, but web does make a bit more sense for PHP projects. If assets:install uses web, then I think we should too.

[RobLoach]

@simensen noted that he uses docroot, web and public depending on what project he's working on. The project web-root does change between projects.

components is what Bower/component use, but assets:install uses web. Will have to do some pondering. What are your thoughts?

Wasn't there talk of adding a public-dir meta-tag to Composer? Maybe we could prepend that to the component-dir.

[simensen]

Given the naming of this project, I'd expect (even if it is not what I would use myself) components/ if I know anything at all about Bower or component. Which I don't actually know much about. :) Still, I would not see this project any more aligned with Symfony than any other project so I would not immediately assume web/.

[pkruithof]

I made the suggestion for web based on the Symfony reference. But I agree with @simensen that components seems to be the de-facto standard, and that this project should be framework/project agnostic.

[RobLoach]

Another possibility: vendor/components

[simensen]

In all (limited) cases that I've used Components installer I've overridden the target directory anyway, so I don't know how useful a default will be for me anyway. So at least at this point my feedback can maybe be taken with a grain of salt. :)

As I pointed out on IRC, the way I see it the main reason to have Components installer at all for Composer is to get the code out of vendor/*. From my perspective, having Components installer default to vendor/components would sort of defeat the purpose.

Then again, it would leave it in vendor/* by default and people can then just opt to put it wherever they want. I can maybe see how that might be useful.

Just some rambling thoughts to add to the mix. :) All in all super happy with this project so far!

[pkruithof]

Thinking about this more, two things come into mind:

1. Since composer is used, there is really one directory you can depend on, and that is vendor.
2. This library imports public assets, which need to be in a (public) document root.

Since every project or framework using this library uses a different document root, there really isn't a default or de-facto standard you can use. Therefore I think the vendor directory is the only logical place. Every project then needs to specify the actual location via the config.

A different use could be that a project doesn't really export the components verbatim, but uses an internal mechanism to do this, such as the assets:install command in Symfony. Because of all the possible use-cases, I think the vendor directory, with optional config override provides enough flexibility and a sensible default.

[hutchic]

Doing most of my work in Symfony2 with Composer I was caught off guard by where the components directory gets created. My $0.02 the vendor directory makes the most sense.

[Nek-]

This idea is great for a Symfony2 user (as I am), but what about the rest of the world ?

When you develop from scratch using composer to manage your own dependancies, the best place is web/ or.. public_html or... root dir (yes, some people use it).

You can't decide ? Not a problem. Let it in vendor folder. After all, the natural composer behavior is not so bad.

[SamMousa]

A simple solution would be to require a manual configuration. And print a warning / notice if no configuration is supplied. (The vendor folder should not be web-accessible so don't promote users to change that)