`name` should only be required for published packages about spec HOT 22 CLOSED

what about name should only be required if private is false or not present?

from spec.

@eddiemonge I guess this would be an ok compromise. The private flag is optional and really only to prevent accidental publication of private repositories. But yeah, I'm ok with this as a compromise.

oops, closed issue by mistake, reopened

from spec.

+1

Coming up with a name for something is often the hardest part. :/ Starting a new project should be as simple as specifying dependencies: {} and private: true.

from spec.

@lukehorvat The private flag shouldn't be required to prevent accidental publication of a private repository. Publication should be opt-in. It might already work like this, if not, then it should. Then, essentially, all you need is dependencies: {}. Best practice would be to set the private flag anyways just to be safe.

from spec.

If you type bower publish it will publish it unless you have the private flag set to true. so its opt-in with accidental publication prevention

from spec.

@eddiemonge opt-in? You say it will publish if you don't have the private flag set to true, that's opt-out. i.e. you're saying the default value for the private flag is false? :)

from spec.

@gerardroche typing publish seems opt-in to me. Also: this seems off-topic. :)

👎 for making "name" optional. Fwiw, optional values, especially "name", make the code more complex for automation tools, and create surprises for developers when/if the tools are forced to provide default values such as "myApp".

from spec.

@unscriptable I don't understand.

• If the name attribute is required then you will need to add a name. your tools are forced to provide a name.
• If the name attribute is not required i.e. optional, then you don't need to do anything. Nothing. nada. Your tools are not forced to do anything. Nothing. Diddly squat.

The name is only required for published packages.

So if your package is published/public i.e. the private flag is false, then it is required.

If the private flag is true, then the name is optional.

from spec.

On the contrary, @gerardroche, our tools require a name to function properly.

Fwiw, if the bower init CLI continues to prompt for name and provides a default, then users will essentially be forced to provide one when creating a bower project. This is sufficient for our tools. Our tools don't care if the package is private or not.

The description of this issue doesn't make it clear whether you're describing a constraint during a bower register operation or a bower init. I'm guessing you're describing bower register? If so, perhaps you could update the description?

from spec.

@unscriptable Your tools currently require a name property to function only because you have coded it that way. However, name should not be required. Not everything that has a bower.json file will be a bower package. If you are making a website, you will probably have bower components. The only way to reliably track those (without checking them in) is to store them in the dependencies in the bower.json file. Why require a name property there if its not needed?

from spec.

Your tools currently require a name property to function only because you have coded it that way.

Not true. They will continue to require a name. We require a name for the application-level bower.json, not just the dependencies. If we (RaveJS) are the only ones who need a name and the general public is truly too lazy to pick a name (or let the tool provide a default one), then I guess we lose this battle.

I checked the npm doc linked above, and it clearly indicates that "name" and "version" are the most important pieces in package.json and are required. However, I know from experience that npm install will continue to work correctly if the "name" and "version" are deleted or otherwise missing. On the other hand, npm init forces a "name" property.

If this is a proposal to allow bower install to work without a "name" property, then I'm certainly 👍. If this is a proposal to stop prompting for "name" during bower init, then I'm adamantly 👎.

from spec.

Why do you require a name? Whats it used for?

If this is a proposal to allow bower install to work without a "name" property, then I'm certainly 👍.

Yes, bower install should work without a name property.

If this is a proposal to stop prompting for "name" during bower init, then I'm adamantly 👎.

Yes bower init could still prompt for a name. Leaving it blank should not add a name property or maybe it adds an empty one.

So that should satisfy you. But making name optional should still be allowed. bower init isn't the only way to create a bower.json file after all.

from spec.

Yeah, I would be pretty happy if Bower acted the same as NPM in this area - prompt for name when running bower init, but don't require it when running bower install.

from spec.

No I'm not advocating that the prompt for name during bower init be dropped.

Leaving it blank should omit the property, rather than adding a blank one.

prompt for name when running bower init, but don't require it when running bower install.

👍

from spec.

Yes bower init could still prompt for a name. Leaving it blank should not add a name property or maybe it adds an empty one.

I disagree. Leaving it blank should fill in a default "name" property, just like bower init and npm init do now.

from spec.

@unscriptable :) a name which is redundant and meaningless. I think how bower init works is another issue. This issue is more about the bower.json spec.

from spec.

name should only be required if private is false or not present

👍

from spec.

It should be aligned with npm

from spec.

Only name and version are required fields in package.json but it won't throw an error if they are missing when installing deps. So I think we should make name required here but don't throw an error if people just wanna install any deps.

from spec.

Agreed that name should be 100% optional for bower config. As pointed out in #160. I shouldn't have to give my project a name if I'm just trying to require some dependencies.

from spec.

This is a very old issue, has it been fixed?

from spec.

doesn't really matter as bower is sort of dead.

from spec.