✅ Deploy Preview for fakerjs ready!

Name	Link
🔨 Latest commit	251ca3c
🔍 Latest deploy log	https://app.netlify.com/projects/fakerjs/deploys/685029efd48f700008550bec
😎 Deploy Preview	https://deploy-preview-3529.fakerjs.dev
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.97%. Comparing base (d07d96d) to head (251ca3c).
Report is 1 commits behind head on next.

@@           Coverage Diff           @@
##             next    #3529   +/-   ##
=======================================
  Coverage   99.97%   99.97%           
=======================================
  Files        2880     2880           
  Lines      220510   220510           
  Branches      952      951    -1     
=======================================
  Hits       220457   220457           
  Misses         53       53           

I have problems with applying the argumentation chain from your description to the "problem" at hand.
Your reasoning regarding script sorting is based on personal preference rather than objective criteria, without presenting a factual conclusion on the matter. The one argument I would agree with is that scripts that belong contextually together, should be put next to each other. But then the question arises for me: Why don’t they share the same prefix? By renaming the scripts to reflect their contextual usage, they would naturally group together:

That said, I’m unsure why this plugin is necessary in the first place. Why must the fields be rearranged every time the formatter runs? If maintaining a specific structure in package.json is important, it can be established once (as seen in #3098) and upheld through processes like code review. Additionally, after a project’s infrastructure is set up, package.json typically doesn’t undergo frequent structural changes.

If this PR ties to resolve the "blocking" dependency update PR #3499 (comment) I'd rather vote to remove the plugin entirely.

The plugin is especially there in the first place so that if a dependency (normal or dev) is instantly correctly ordered without thinking about it.

I'm not against grouping them by test: prefixes, go for it and do a PR if this makes you happy :)

Potentially we have all our opinions and need to find a way to live with it. But if you have hard broke feelings by a conflict in mind of how sort orders should be or should not be done, then okay, do a PR and remove the plugin completely and I will approve.

However, I'm very unhappy about the forced change within a bugfix release of a plugin going against my opinions.
I just put the energy into contributing into prettier-plugin-pkg and I'm happy with the results and use it in packages I fully control. So I already benefit from it.

But anyway, doing something in Faker is becoming always a fight and start to not have hard feelings about it anymore 🤷

I gave my arguments why I did it, you are not satisfied with it, so be it.

@xDivisionByZerox sorry... I hope we can solve the problem somehow. But I gave some arguments that I hope you can understand like the visually eye-scanning for the preflight command.
I just don't like that nearly always you encounter with some vetos where potentially is no problem for you.
I have the problem that it conflicts with that the dependency tries to forcefully sort scripts where the scripts are more important to also be read by humans. And yeah adding prefixes can potentially solve it to some degree, but even then e.g. I would like to have unit tests run before integration tests or e2e tests.
So when we now have e.g.

test:unit
test:coverage
test:integration
test:e2e

the plugin would still ignore what humans can thinks and organize into this structure and just forcefully sort it by alphabetical order. And I really dont like that.

But on the other hand, having all the other things sorted automatically like dependencies and files and keywords etc, is helping us maintainers to not further think about it, but let the plugin do its job.

When we want a sorting and/or prefixing change in our scripts, then lets discuss it in a separate thread. I'm fine with that.
But just doing a veto where I put now a day of work into it by contributing fells a bit painful tbh.

1. I did not use the word "veto" in any of my comments. The word "veto" is a strong absolute stand when coming to an agreements. So to be very clear I did not and do not veto this change.
2. I truly do not understand how having a discussion "becomes always a fight" for you. Like do you always get your way at work? How are you working in a team if not through constructive argumentations on a conceptual level? I am not fighting you. I provide counter arguments to your stand to see if your argumentation can withstand them. If not, your point couldn't have been that great could it? I'm not here to fight with you. I'm here to question if a change does truly improve the project for the users or maintainer or not.
3. Nobody asked you to do that work. There was no reason, other than your personal matters in disliking a specific sorting in an established package. I agree that changing the sorting of your library in a patch version is off-putting, BUT this library is an opinionated approach on sorting fields in the file. If you do not agree with the opinion, that package is not for you. I know that this will not be as big of an argument, but prettier did this in a non-major version before as well and we still use it 🤷‍♀️

3. Nobody asked you to do that work. There was no reason, other than your personal matters in disliking a specific sorting in an established package. I agree that changing the sorting of your library in a patch version is off-putting, BUT this library is an opinionated approach on sorting fields in the file. If you do not agree with the opinion, that package is not for you. I know that this will not be as big of an argument, but prettier did this in a non-major version before as well and we still use it 🤷‍♀️

But the new/alternative package now has an option for this, plus it has less sub-dependencies, and it archives the same goal as the other plugin in its prior version where the forcement did not happen.

I think the issue I have with your comments is that they just and only come up with counter arguments to check if my already given arguments are valid and stand their point. Instead I would like to get some constructive critic.

However I do not see any blocker between adding the test: prefixes AND use the new alternative package.

However removing the old package... this is to me a destructive critic. And maybe this raged my anger.

I assume I misread into the I'd rather vote to remove the plugin and mistakenly remembered in my head that you wrote veto somewhere in your text, without rechecking it.
But good that you don't have a veto.

tldr conclusion:

my arguments for why doing this change:

• less sub-dependencies
• the plugin has its own opinionation by default, but allows to configure it with out opinions
• the package was written in typescript (definitely something optional)
• the package is part of the ecosystem/community I live in (definitely something optional)

these are my points, I do not have more

removing the old plugin without a replacement is also not a constructive option to me, cause IMO ...

That said, I’m unsure why this plugin is necessary in the first place. Why must the fields be rearranged every time the formatter runs? If maintaining a specific structure in package.json is important, it can be established once (as seen in #3098) and upheld through processes like code review. Additionally, after a project’s infrastructure is set up, package.json typically doesn’t undergo frequent structural changes.

... is not very constructive. We added it so random contributors e.g. do not accidentally put a new devDependency somewhere by hand. sorting the package.json in a given structure reduces marge conflicts.

Maybe when I now think more and more about it, one of my main issues was that your comment started with I have problems with ... as an introduction. Which instantly puts the whole context into a position of negativity.
Just a tip, you don't need to read it, but maybe it can help: https://blog.wordvice.com/grammar-avoid-double-negatives/
Maybe this helps a bit to understand how it come over to me.