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

feat(publish): add --access flag to publish command #299

Merged
merged 1 commit into from
Sep 14, 2018
Merged

Conversation

ashleygwilliams
Copy link
Member

fixes #297

match s {
"public" => Ok(Access::Public),
"restricted" => Ok(Access::Restricted),
"private" => Ok(Access::Restricted),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doing something a little unconventional here but i seriously cannot believe that it's "restricted" and not "private" so i kiiiiiinda want to have this in here, but if ya'll object i'm cool with removing it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the npm wording is "restricted" but this is creating an alias to that named "private"? I'd prefer just matching what npm does.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The indentation here is super funky too

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the alias personally. wow cargo fmt what is you doing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i talked with nick and am gonna file an issue, it's a bug in cargo fmt, likely from the long string literal

"restricted" => Ok(Access::Restricted),
"private" => Ok(Access::Restricted),
_ => Err(Error::Unsupported { message: format!("{} is not a supported access level. See https://docs.npmjs.com/cli/access for more information on npm package access levels.", s)}),
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also really not sure what's up with the formating here, i ran cargo fmt but this is nasty

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe if you manually add some \ followed by a newline in the middle of the format string?

@ashleygwilliams
Copy link
Member Author

i actually just realized that if you pass --access="" npm gets mad. i was hoping it was just do it's default. do we want to change how the access level defaults? if yes, i can make a small change, if no i can make a bigger one. i'm thinking probably no, so this will require a small amount of work before it can be merged.

@ashleygwilliams ashleygwilliams added question Further information is requested work in progress do not merge! labels Sep 11, 2018
@ashleygwilliams ashleygwilliams changed the title feat(publish): add --access flag to publish command [WIP] feat(publish): add --access flag to publish command Sep 11, 2018
@fitzgen
Copy link
Member

fitzgen commented Sep 11, 2018

do we want to change how the access level defaults? if yes, i can make a small change, if no i can make a bigger one. i'm thinking probably no, so this will require a small amount of work before it can be merged.

While I personally think that access should default to public, I don't think it is worth creating inconsistencies with npm over.

Copy link
Member

@fitzgen fitzgen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Will be great to have this fixed.

A couple tiny suggestions below, that I think would improve things a bit.

#[structopt(long = "access", short = "a")]
access: Option<Access>,

/// The access level for the package to be published
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment should be on the field above, and the comment for the field above should be here :-p

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

d'oh. good catch.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is still unaddressed ;)

match s {
"public" => Ok(Access::Public),
"restricted" => Ok(Access::Restricted),
"private" => Ok(Access::Restricted),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the npm wording is "restricted" but this is creating an alias to that named "private"? I'd prefer just matching what npm does.

match s {
"public" => Ok(Access::Public),
"restricted" => Ok(Access::Restricted),
"private" => Ok(Access::Restricted),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The indentation here is super funky too

"restricted" => Ok(Access::Restricted),
"private" => Ok(Access::Restricted),
_ => Err(Error::Unsupported { message: format!("{} is not a supported access level. See https://docs.npmjs.com/cli/access for more information on npm package access levels.", s)}),
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe if you manually add some \ followed by a newline in the middle of the format string?

Restricted => "restricted",
},
None => "",
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about instead of making this stringly typed again, we implement Display for Access, implement Default for Access, and then right here do

access.unwrap_or_default()

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the use of Display to not have to worry about strings and have it be centralized to one spot so that calls to to_string() will be consistent as well

Copy link
Member Author

@ashleygwilliams ashleygwilliams Sep 12, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ack. i just reread your message and realized i had missed the "again". anyways, yes, using Display is a good call.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the one thing to note is that we can't implement a default- this is because the default changes depending on whether or not the package is scoped, which we don't currently track. i need to think about whether i think it's a good idea to do so, but i had a plan for how to do the default that didn't involve tracking whether it was scoped so i may try that first.

src/npm.rs Outdated
@@ -18,10 +18,11 @@ pub fn npm_pack(path: &str) -> Result<(), Error> {
}

/// Run the `npm publish` command.
pub fn npm_publish(path: &str) -> Result<(), Error> {
pub fn npm_publish(path: &str, access: &str) -> Result<(), Error> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And then this argument would be access: Access and we know that we can't ever pass a bad access here

Copy link
Contributor

@mgattozzi mgattozzi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pretty much agree with @fitzgen on most of this so if you make the changes he suggested (I personally want the alias) then you can consider this an approval from me

match s {
"public" => Ok(Access::Public),
"restricted" => Ok(Access::Restricted),
"private" => Ok(Access::Restricted),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the alias personally. wow cargo fmt what is you doing.

Restricted => "restricted",
},
None => "",
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the use of Display to not have to worry about strings and have it be centralized to one spot so that calls to to_string() will be consistent as well

@ashleygwilliams
Copy link
Member Author

failing re doc comments now- gonna fill those out but i think i have one more refactor to make this nicer. it's too bad that the npm access flag doesn't take a default, e.g. --access=default, but i have a plan, that also cleans up the duplication in src/npm.rs

@ashleygwilliams ashleygwilliams added needs rebase and removed needs docs please add docs to this PR work in progress do not merge! blocked question Further information is requested labels Sep 14, 2018
Copy link
Member

@fitzgen fitzgen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! r=me with that comment below fixed :)

#[structopt(long = "access", short = "a")]
access: Option<Access>,

/// The access level for the package to be published
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is still unaddressed ;)

@ashleygwilliams ashleygwilliams changed the title [WIP] feat(publish): add --access flag to publish command feat(publish): add --access flag to publish command Sep 14, 2018
@ashleygwilliams ashleygwilliams added this to the 0.5.0 milestone Sep 14, 2018
@mgattozzi
Copy link
Contributor

This LGTM great job! Let's get it merged

@mgattozzi mgattozzi merged commit 6ad8b0f into master Sep 14, 2018
@ashleygwilliams ashleygwilliams deleted the access-flag branch January 13, 2019 22:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

support --access flag to publish command
3 participants