-
-
Notifications
You must be signed in to change notification settings - Fork 74
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
change -o/--os
to -p/--platform
#337
Conversation
-o/--os
to -p/--platform
Any idea what's wrong with the failed test here? |
@marchersimon don't edit this PR yet—I'm making some changes. |
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. |
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. |
Oh, sorry, I just blindly replaced |
There we go, the checks are all green. |
There was a problem hiding this 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!) 😄
There was a problem hiding this 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'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const platformUtils = require('../lib/platformUtils'); | |
const Platform = require('../lib/platform'); |
Makes diff smaller and addresses name clash in a fairly standard manner.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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? 😕
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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
👍🏻
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
😉
There was a problem hiding this comment.
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 😂
OT Please don't do that because it generates notification noise. You can always manually rerun Github actions through the web interface. |
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'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let platformUtils = require('./platformUtils'); | |
const platformUtils = require('./platformUtils'); |
@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 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? |
There was a problem hiding this 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.
Yeah you're right @agnivade, funny that I didn't think about that. What about also printing a deprecation message when |
Sounds reasonable. It can be removed in the next major release. |
Should I still handle suggestions or would you prefer to take over? Because I think I wouldn't be very helpful here. |
Oh, I had a message typed but forgot to hit send 🙃 I'll take over, provided you don't mind. |
Sure, thank you |
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 🙃 |
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 |
Looks nice, I'll try it. The message might be developer-oriented rather user-oriented, but we'll see.
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>
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?) |
No, I don't think so! Another spec compliance issue! 😄 I will gladly take care of that ASAP once this PR is merged. |
Is this ready for review? This still seems to replace |
Oh, sorry, you're right. I just saw that the PR hasn't had activity for some time. |
I think this PR is indeed ready for review, @agnivade |
Closing this in favor of #421 |
Closes #336