-
Notifications
You must be signed in to change notification settings - Fork 91
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: sort all scripts unless npm-run-all
is a dependency
#232
Conversation
Doesn't cover |
The idea is good, but the implementation is bad, we should not pass I would check |
@fisker I'm not sure if I'd say that's a better solution - the advantage I see with passing If you were to make a different That's if I understand your thinking correctly - I've not done a lot of work with this sort of functional currying & piping layout so it's possible I've missed an easy trick :) |
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'd result in something more complex and special-case-y since it would be devoted purely to the scripts fields
You are right, I was misleading by the parameter names, what do you think my suggestions bellow?
index.js
Outdated
const overProperty = (property, over) => (object, packageJson) => | ||
hasOwnProperty(object, property) | ||
? Object.assign(object, { [property]: over(object[property]) }) | ||
? Object.assign(object, { [property]: over(object[property], packageJson) }) | ||
: object |
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 overProperty = (property, over) => (object, packageJson) => | |
hasOwnProperty(object, property) | |
? Object.assign(object, { [property]: over(object[property]) }) | |
? Object.assign(object, { [property]: over(object[property], packageJson) }) | |
: object | |
const overProperty = (property, over) => (object, ...args) => | |
hasOwnProperty(object, property) | |
? Object.assign(object, { [property]: over(object[property], ...args) }) | |
: object |
I'm not too opposed to them, but am interested in what others think as I originally did have the code like that, but the problem I saw was that to me it means you don't have this strong guarantee/implication that the parameter is/should-be the package json that was passed in which is part of the underlying idea: that a field is ensured it'll be passed whatever the value of the field is and the whole package json object. For me this is the sort of thing where I'd feel more comfortable using a general spread if I was writing TypeScript because I know that'll be able to ensure I'm getting passed the right properties for the field function I'm writing but when writing plain Javascript I prefer having that extra distention. Additionally, this is all internal API - so shipping it how it is right now shouldn't later prevent switching to using a spread if there becomes a reason to sometimes pass more than one argument or an argument that isn't the whole package json object. tl;dr: I don't know if there's a lot of value in using spread right now when we're always passing in the same two values, vs the extra clarity of using named parameter 🙂 |
I don't think that either approach is too bad. I don't think that dragging json is too bad for perf. But maybe better for ease of understanding. Either way, I haven't contributed to this package, so I'm going to let you guys decide. I'm just excited to see #220 fixed asap :) |
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 like the concepts in the code, I also agree with @fisker's assessment and code comments. Let's keep the "lib" stuff generic and then 🚢
@keithamus are you ok to just commit the suggestions made by @fisker that you want made, since that should be all that's needed but I'm not at my laptop right now 😅 |
Co-authored-by: fisker Cheung <lionkay@gmail.com>
🎉 This PR is included in version 1.52.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Posting here too for visibility: You can also add numerics to your script names to force a specific sort order while retaining the ability to automatically alphanumeric sort. IMO this is preferable than adding tool specific behaviors. |
This restores the default behaviour of sorting scripts alphabetically followed by pre & post unless
npm-run-all
is a development dependency in thepackage.json
being sorted.Closes #220