Opinions on exports order (setting the `types` key first) breaks monorepos

[cefn]

Please note the explicit guidance on Custom conditions for monorepos at from the author of zod who I consider an authority on typescript practices...

You should put your custom condition first. Order matters! It's important that your custom condition is the first one in the list (even before "types").

https://colinhacks.com/essays/live-types-typescript-monorepo

The change to force this order breaks systems in a major way.

Within the "exports" object, key order is significant. During condition matching, earlier entries have higher priority and take precedence over later entries. The general rule is that conditions should be from most specific to least specific in object order.

https://nodejs.org/api/packages.html#conditional-exports

it's nice to have the keys of a package.json in a well sorted order.

Object order in package.json is part of the node resolution API, it's not a nice formatting aspect to help with diffs or styling.

The result of this particular opinionated ordering was to break every module and server in our monorepo meaning we will have to remove tooling for package ordering via https://github.com/matzkoh/prettier-plugin-packagejson which brought through the change.

I'm guessing #294 (comment) is a comment on a feature discussion and therefore won't be considered a live issue. So I'm raising this here as an issue so that it can at least be considered

In the circumstances I imagine we just have to stop formatting package.json. I suspect from reading discussion that this upstream will stay this way, which is of course your right, but please consider how being opinionated in this way may end up actually breaking things very badly in ways that are nearly impossible to trace, and that people will struggle with the consequences.

Working in an ecosystem where navigating a functioning intersection between all the opinionated tools, the cost of these arbitrary decisions compounds. For every opinionated tool fighting it out with all the others, the last move in the venn diagram can end up excluding systems from even functioning.

It's a particular shame because monorepos is exactly where this kind of tooling and consistency matters and I am sad to abandon it.

[cefn]

For a more substantial reference case than our private enterprise repo, you could consider how this choice of package formatting would break the zod project - 70 million downloads a week https://github.com/colinhacks/zod/blob/9977fb0868432461de265a773319e80a90ba3e37/packages/zod/package.json#L54-L113

[keithamus]

PRs welcome if you can improve upon the existing heuristics! The goal of the project is to simply deterministically sort the package.json. If some fields are order dependant, we shouldn't sort them.

[cefn]

Thanks for the offer @keithamus trying to achieve this, but there's no Fork interaction I can see against this repo.

Does this need to be turned on these days? https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-forking-policy-for-your-repository

Alternatively if there's a way to add me as contributor somewhere?

There is a PR from a standalone repository under my user account at https://github.com/cefn/sort-package-json/pull/1 but because my repo doesn't have a Forked identity against your repo (even though it has the same commit history) I can't raise this as a PR against your repo.

[keithamus]

Thanks for the offer @keithamus trying to achieve this, but there's no Fork interaction I can see against this repo.

Does this need to be turned on these days? docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-forking-policy-for-your-repository

Alternatively if there's a way to add me as contributor somewhere?

There is a PR from a standalone repository under my user account at cefn/sort-package-json#1 but because my repo doesn't have a Forked identity against your repo (even though it has the same commit history) I can't raise this as a PR against your repo.

If you already have a repo with the same name in your account, you'll be unable to fork. You have a couple of options:

1. Rename the repository of the same name in your account.
2. Delete the repository of the same name in your account.

Given the repository of the same name in your account looks to be a "detached fork" it might be safe to delete it, then click the fork button within GitHub, then you can simply push branches to your fork so you don't lose any changes you've made.

[cefn]

Sure no problem deleting it. But I created it manually because I couldn't see a fork interaction. I'll delete and see if I can find another way.

[keithamus]

The URL should be https://github.com/keithamus/sort-package-json/fork

[regseb]

The Node.js documentation Community Conditions Definitions specifies that the "types" property must be first.

"types" - can be used by typing systems to resolve the typing file for the given export. This condition should always be included first.

---

And in Conditional exports, it's specified that the "default" property must be last.

"default" - the generic fallback that always matches. Can be a CommonJS or ES module file. This condition should always come last.

[cefn]

Not sure how node has a horse in the race about the interpretation of the types field, when typescript resolutions and syntax is always ignored by node, for obvious reasons.

The guidance to place "types" first without justification here is contradicted by the previous sentence, which points to the mechanism by which you can dictate your own conditions...

Other platforms may implement other conditions and user conditions can be enabled in Node.js via the --conditions / -C flag.

Taken with...

Within the "exports" object, key order is significant. During condition matching, earlier entries have higher priority and take precedence over later entries. The general rule is that conditions should be from most specific to least specific in object order.

The feature of user conditions relies on being able to place non-standard strings (like 'my-condition') before standard strings (like 'types', 'import', 'require') and dictate order. The first accepted resolution (by the consuming process) will always dominate. So if "types" is always first, then there can be no 'user conditions' at all for tooling that consumes typings, since "types" is always an accepted resolution.

More directly relevant is https://www.typescriptlang.org/tsconfig/#customConditions from the Typescript documentation where in their example they have to place the customCondition my-condition in first position. But even for typescript there will be a long tail of bad documentation from before the Typescript 5.x.x version when support for customConditions was introduced.

Enforcing a formatting convention that prevents the use of the Typescript custom conditions feature isn't sustainable for us at least.