Skip to content
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

name should only be required for published packages #22

Closed
gerardroche opened this issue Mar 3, 2014 · 22 comments
Closed

name should only be required for published packages #22

gerardroche opened this issue Mar 3, 2014 · 22 comments

Comments

@gerardroche
Copy link

name should only be required for published packages.

In example, both composer and npm only require a name for published packages.

See also version attribute should always be required #4

@eddiemonge
Copy link

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

@gerardroche
Copy link
Author

@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

@lukehorvat
Copy link

+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.

@gerardroche
Copy link
Author

@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.

@eddiemonge
Copy link

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

@gerardroche
Copy link
Author

@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? :)

@unscriptable
Copy link

@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".

@gerardroche
Copy link
Author

@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.

@unscriptable
Copy link

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?

@eddiemonge
Copy link

@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?

@unscriptable
Copy link

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 👎.

@eddiemonge
Copy link

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.

@lukehorvat
Copy link

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.

@gerardroche
Copy link
Author

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.

👍

@unscriptable
Copy link

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.

@gerardroche
Copy link
Author

@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.

@stevemao
Copy link

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

👍

@stevemao
Copy link

It should be aligned with npm

@stevemao
Copy link

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.

@JoshMcCullough
Copy link

JoshMcCullough commented Feb 13, 2016

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.

@gerardroche
Copy link
Author

gerardroche commented Sep 22, 2017

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

@eddiemonge
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

7 participants