Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

change -o/--os to -p/--platform #337

Closed
wants to merge 5 commits into from
Closed

change -o/--os to -p/--platform #337

wants to merge 5 commits into from

Conversation

marchersimon
Copy link
Contributor

Closes #336

@bl-ue bl-ue changed the title change -o to -p and --os to --platform change -o/--os to -p/--platform Mar 26, 2021
@marchersimon
Copy link
Contributor Author

Any idea what's wrong with the failed test here?

@bl-ue bl-ue closed this Mar 26, 2021
@bl-ue bl-ue reopened this Mar 26, 2021
@bl-ue
Copy link
Contributor

bl-ue commented Mar 26, 2021

@marchersimon don't edit this PR yet—I'm making some changes.

@bl-ue
Copy link
Contributor

bl-ue commented Mar 26, 2021

Closing→reopening the PR can frequently fix the checks, not the case here. I think you may have broken it, let me see. I'll also re-run the jobs.

@bl-ue
Copy link
Contributor

bl-ue commented Mar 26, 2021

The tests should pass now. FYI @marchersimon when you change the flags in the code (here) you also need to update references to that flag, e.g. program.os (here) corresponds directly to the string values passed to program.option, so it needs to be changed to program.platform. All of that and more I've done in the past two commits 👍🏻

@bl-ue bl-ue requested review from vladimyr and agnivade March 26, 2021 20:56
@marchersimon
Copy link
Contributor Author

Oh, sorry, I just blindly replaced -o and --os without checking if they occur somewhere else. Thanks for the fix

@bl-ue
Copy link
Contributor

bl-ue commented Mar 26, 2021

There we go, the checks are all green.

Copy link
Contributor

@bl-ue bl-ue left a comment

Choose a reason for hiding this comment

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

Funny that the most official of all the official clients doesn't even comply with the spec (in a big way!) 😄

Copy link
Collaborator

@vladimyr vladimyr left a comment

Choose a reason for hiding this comment

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

Looks good overall, just a few suggested changes 👍
@marchersimon Thanks for addressing it.

@@ -4,7 +4,7 @@ const program = require('commander');
const pkg = require('../package');
const Tldr = require('../lib/tldr');
const config = require('../lib/config');
const platform = require('../lib/platform');
const platformUtils = require('../lib/platformUtils');
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
const platformUtils = require('../lib/platformUtils');
const Platform = require('../lib/platform');

Makes diff smaller and addresses name clash in a fairly standard manner.

Copy link
Contributor

Choose a reason for hiding this comment

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

You think so? I mean to ask you in the extended commit message of 5e1b052

Copy link
Collaborator

Choose a reason for hiding this comment

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

Well, I've seen it more than once in various node codebases but that is anecdotal evidence. Maybe going with

const platforms = require('../lib/platforms');

strikes the right balance?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't have strong opinions regarding either, but do you think platformUtils it not standard?

Copy link
Collaborator

@vladimyr vladimyr Mar 28, 2021

Choose a reason for hiding this comment

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

utils and helpers are well-known wildcards conveying absolutely zero meaning so some folks consider naming things using them as an antipattern. In this case, it has been used as a name-clash avoiding suffix so it isn't a problem except it hurts my eyes 🙈
But let's take a step back, what exactly mandates rename in the first place, I failed to spot that name clash we are trying to avoid here? 😕

Copy link
Collaborator

Choose a reason for hiding this comment

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

That's the same situation as requiring the path module and then having a variable named path. In most cases platform is really accessed as a property of the program object which makes it a non-issue. And if there are some shadowing instances they should be addressed by renaming the local variable instead, for example, targetPlatform or selectedPlatform.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, you're thinking the right way. I guess I'm busy so I didn't think a lot about this. I'll change the name back to platform.js 👍🏻

Copy link
Contributor

@bl-ue bl-ue Mar 28, 2021

Choose a reason for hiding this comment

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

What would you do about cases like this?

function validatePlatform(platform) {
  if (platform && !platformUtils.isSupported(platform)) {
    return 'Unsupported platform : ' + platform;
  }
  return null;
}

Personally I'd pick p as a parameter name, but that doesn't strike my memory as conventional JS (I'm not working on much js lately)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Well if you do validation then one thing is for sure, you are doing it on input 😉

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah, you're thinking the right way. I guess I'm busy so I didn't think a lot about this. I'll change the name back to platform.js 👍🏻

Watching me doing things you would soon realize that most of the time it seems like I'm not thinking at all 😂

@vladimyr
Copy link
Collaborator

vladimyr commented Mar 27, 2021

Closing→reopening the PR can frequently fix the checks, not the case here. I think you may have broken it, let me see. I'll also re-run the jobs.

OT Please don't do that because it generates notification noise. You can always manually rerun Github actions through the web interface.

@bl-ue
Copy link
Contributor

bl-ue commented Mar 27, 2021

You're right; I realized that after I closed/reopened it 😂

@@ -4,6 +4,7 @@ const defaults = require('lodash/defaults');
const fs = require('fs');
const path = require('path');
const osHomedir = require('os').homedir;
let platformUtils = require('./platformUtils');
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
let platformUtils = require('./platformUtils');
const platformUtils = require('./platformUtils');

@bl-ue
Copy link
Contributor

bl-ue commented Mar 27, 2021

@vladimyr this is all great stuff that you're pointing out, but as it doesn't actually improve the app from the users's perspective (i.e. performance, etc.) what do you think about ignoring all of these tweaks for this PR and saving them for another PR? I plan to open a new PR within the next couple days full of improvements I've noticed could be made and I think these would—as they're not strictly related to the osplatform change—be better for that PR.

I have a lot more things in mind than you're pointing out here, and IMO it makes the diff harder while not giving the code the wash it deserves. What do you think?

Copy link
Member

@agnivade agnivade left a comment

Choose a reason for hiding this comment

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

Thanks for the PR. However, changing an option outright is a huge breaking change. Let's add the --platform option which can be a synonym for --os so that existing users aren't affected.

@bl-ue
Copy link
Contributor

bl-ue commented Mar 27, 2021

Yeah you're right @agnivade, funny that I didn't think about that. What about also printing a deprecation message when -o/--os are used, stating that they will be removed in a future release or after a specific date e.g. Dec 31 2021?

@agnivade
Copy link
Member

Sounds reasonable. It can be removed in the next major release.

@marchersimon
Copy link
Contributor Author

Should I still handle suggestions or would you prefer to take over? Because I think I wouldn't be very helpful here.

@bl-ue
Copy link
Contributor

bl-ue commented Mar 27, 2021

Oh, I had a message typed but forgot to hit send 🙃 I'll take over, provided you don't mind.

@marchersimon
Copy link
Contributor Author

Sure, thank you

@vladimyr
Copy link
Collaborator

@vladimyr this is all great stuff that you're pointing out, but as it doesn't actually improve the app from the users's perspective (i.e. performance, etc.) what do you think about ignoring all of these tweaks for this PR and saving them for another PR? I plan to open a new PR within the next couple days full of improvements I've noticed could be made and I think these would—as they're not strictly related to the osplatform change—be better for that PR.

I have a lot more things in mind than you're pointing out here, and IMO it makes the diff harder while not giving the code the wash it deserves. What do you think?

So here is what I think. You are right changes I proposed are transparent to the end-user and don't affect them in any possible way but they improve the state of a particular piece of codebase limited by boundaries of this patch/PR. I tend to follow Martin Fowler's school of thought there which can be summarised as - each time you touch some part of the codebase go and make it a bit better right away instead of scheduling grand refactors.

As per your second point, I fully agree that there are countless things that need to get addressed in tldr's codebase but please make that an incremental process rather than one big rewrite.

This last point of yours about making the diff harder I can just say I explicitly limited myself to not suggest too many changes and to keep those on topic. I think I did a good job there but that's obviously subjective 🙃

@vladimyr
Copy link
Collaborator

Also as @agnivade pointed out this is a breaking change so increasing of major version is a semver requirement.

For displaying deprecation message, we could use https://www.npmjs.com/package/depd#deprecating-property-access

@bl-ue
Copy link
Contributor

bl-ue commented Mar 28, 2021

For displaying deprecation message, we could use https://www.npmjs.com/package/depd#deprecating-property-access

Looks nice, I'll try it. The message might be developer-oriented rather user-oriented, but we'll see.

So here is what I think. ...
...
This last point of yours about making the diff harder I can just say I explicitly limited myself to not suggest too many changes and to keep those on topic. I think I did a good job there but that's obviously subjective 🙃

Good points, I agree with all of them. I'll apply the suggestions and keep future cleanup PRs small and limited to a particular type of fix.

Co-authored-by: Dario Vladović <d.vladimyr@gmail.com>
@sbrl
Copy link
Member

sbrl commented Mar 30, 2021

I'm sure there'll be plenty of other PRs to the Node.js client here to improve things in too lol

(did we update the Node.js client to automatically convert the page name to lowercase?)

@bl-ue
Copy link
Contributor

bl-ue commented Mar 30, 2021

No, I don't think so! Another spec compliance issue! 😄 I will gladly take care of that ASAP once this PR is merged.

@agnivade
Copy link
Member

Is this ready for review? This still seems to replace --os by --platform.

@marchersimon
Copy link
Contributor Author

Oh, sorry, you're right. I just saw that the PR hasn't had activity for some time.

@sbrl
Copy link
Member

sbrl commented Apr 22, 2021

I think this PR is indeed ready for review, @agnivade

@vladimyr
Copy link
Collaborator

I think this PR is indeed ready for review, @agnivade

It still lacks deprecation notice and as @agnivade already said simply replaces --os by --platform thus introducing a breaking change. ⚠️ ie this needs more work/love...

@MasterOdin
Copy link
Contributor

Closing this in favor of #421

@MasterOdin MasterOdin closed this Oct 13, 2023
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

-o and --os is not compliant with the client spec
6 participants