Put lifecyle scripts to the top of `scripts`

[zanminkian]

Input:

{
  "scripts": {
    "install": "npm run build",
    "prepare": "husky",
    "build": "tsc",
    "lint": "eslint .",
    "test": "vitest run"
  }
}

Expted:

{
  "scripts": {
    "install": "npm run build",
    "prepare": "husky",
    "build": "tsc",
    "lint": "eslint .",
    "test": "vitest run"
  }
}

Actual:

{
  "scripts": {
    "build": "tsc",
    "install": "npm run build",
    "lint": "eslint .",
    "prepare": "husky",
    "test": "vitest run"
  }
}

Lifecycle scripts: https://docs.npmjs.com/cli/v8/using-npm/scripts#life-cycle-scripts

Related: #353 #171

[keithamus]

Seems reasonable but we should get people who are interested in how scripts are sorted to comment here, for e.g. @muuvmuuv, @cefn, @nrjdalal, @Yaman-kumarsahu, @karlhorky, and I am sure others.

Also @fisker.

I think if we can all agree that this is a worthwhile change and doesn't present problems, then we can move forward with a PR. Until then I would hold off to avoid disappointment.

[cefn]

Given alphabetical order is predictable and scripts is an open namespace I would oppose this on the following grounds...

The next time this lands it will force a non-functional change for all projects in our monorepos, confusing the actual content of PRs and therefore going against the core purpose of consistent package structure (meaning which for us is roughly make diffs and comparisons consistent and readable). A whole load of projects which have not changed their scripts will then have an apparent diff pulled through in an arbitrary PR

It will be a net reduction in usability, since we will not be able to easily find scripts in any predictable order. I doubt regular users would understand the scheme. Most people don't even know the full list of lifecycle script names anyway.

This is by contrast to the top level names in which things like name, version exports are obviously distinctive in purpose and significant for navigation and identity when loading and reading package json, (meaning alphabetical sorting would be counterproductive) and therefore should be first.

In this case, given the flat name space changing the order itself is counterproductive

It's not uncommon for the list to grow to 15 or 20 individual scripts. This seems like a change without benefit.

However, I accept the value in general of having a community-maintained scheme so would just swallow the cost if this was decided it was good on some grounds.

[cefn]

Given alphabetical order is predictable and scripts is an open namespace I would oppose this on the following grounds...

The next time this lands it will force a non-functional change for all projects in our monorepos, confusing the actual content of PRs and therefore going against the core purpose of consistent package structure (meaning which for us is roughly make diffs and comparisons consistent and readable). A whole load of projects which have not changed their scripts will then have an apparent diff pulled through in an arbitrary PR

It will be a net reduction in usability, since we will not be able to easily find scripts in any predictable order. I doubt regular users would understand the scheme. Most people don't even know the full list of lifecycle script names anyway.

This is by contrast to the top level names in which things like name, version exports are obviously distinctive in purpose and significant for navigation and identity when loading and reading package json, (meaning alphabetical sorting would be counterproductive) and therefore should be first.

In this case, given the flat name space changing the order itself is counterproductive

It's not uncommon for the list to grow to 15 or 20 individual scripts. This seems like a change without benefit.

[zanminkian]

Separate scripts into 2 parts: one part includes lifecycle scripts and the other part includes normal scripts. Each part is alphabetical. By doing this, scripts is predictable and easy to be found. Because developers who use lifecycle scripts in scripts must know which part is lifecyle scripts and which part is normal scripts.

[karlhorky]

I like the idea of separating hooks into npm lifecycle and user scripts, since they have different behaviors.

And sorting them first seems to somewhat mirror common sorting of imports:

import { writeFile } from 'node:fs/promises'; // Platform
import { formatUsername } from './formatters.ts'; // User

However, I'm not sure about both being alphabetical. The user scripts part for sure. But maybe it's better to sort the npm lifecycle scripts part by groups of "unprefixed functions", so:

{
  "scripts": {
    "preinstall": "", // "install" block starts here
    "install": "",
    "postinstall": "",
    "prepublishOnly": "", // "publish" block starts here
    "publish": "",
    "postpublish": "",
    "prerestart": "", // "restart" block starts here
    "restart": "",
    "postrestart": "",
    "build": "" // User scripts here
  }
}

Would make it a lot more readable if there could be a separator like a new line between the 2 sections (possibly also between the "unprefixed functions" groups but that may be confusing if there's only 1 in a group). It seems like Prettier doesn't remove the empty line:

{
  "scripts": {
    "preinstall": "",
    "install": "",
    "postinstall": "",
    "prepublishOnly": "",
    "publish": "",
    "postpublish": "",
    "prerestart": "",
    "restart": "",
    "postrestart": "",

    "build": ""
  }
}

[zanminkian]

Obviously, your design is better than mine. I totally agree with you. @karlhorky