bug: packageJson.exports.types should be always be ordered first

[jlarmstrongiv]

Failing Example:

{
  "name": "rcva",
  "version": "1.0.6",
  "private": false,
  "description": "React Class Variance Authority 🧬",
  "keywords": [
    "React Class Variance Authority",
    "react-class-variance-authority",
    "classes",
    "classname",
    "classnames",
    "css",
    "rcva",
    "stitches",
    "vanilla-extract",
    "variants",
    "windstitch"
  ],
  "homepage": "https://github.com/jlarmstrongiv/rcva/blob/main/packages/core/README.md",
  "bugs": "https://github.com/jlarmstrongiv/rcva/issues",
  "repository": "https://github.com/jlarmstrongiv/rcva.git",
  "license": "MIT",
  "author": "John L. Armstrong IV",
  "sideEffects": false,
  "type": "module",
  "exports": {
    ".": {
      "require": "./dist/index.cjs",
      "import": "./dist/index.js",
      "types": "./dist/index.d.ts"
    },
    "./package.json": "./package.json"
  },
  "main": "dist/index.cjs",
  "module": "dist/index.js",
  "source": "src/index.tsx",
  "types": "dist/index.d.ts",
  "files": [
    "dist"
  ],
  "scripts": {
    "build": "tsup-node"
  },
  "devDependencies": {
    "@types/react": "^18.0.31",
    "@types/react-dom": "^18.0.11",
    "rimraf": "^4.4.1",
    "tsup": "^6.7.0",
    "typescript": "^5.0.0"
  },
  "peerDependencies": {
    "@leafygreen-ui/polymorphic": "^1.3.0",
    "class-variance-authority": ">= 0.5.1 < 1",
    "react": "^18.0.0",
    "react-dom": "^18.0.0",
    "tailwind-merge": "^1.11.0"
  }
}

More specifically, Should be the first in the object as required by TypeScript. according to publint.dev:

{
  "exports": {
    ".": {
      "require": "./dist/index.cjs",
      "import": "./dist/index.js",
      "types": "./dist/index.d.ts"
    },
    "./package.json": "./package.json"
  }
}

EXPORTS_TYPES_SHOULD_BE_FIRST

Ensure types condition to be the first. The TypeScript docs recommends so, but it's also because the exports field is order-based.

For example, a scenario where both the types and import condition could be active, types should be first so that it matches and returns a .d.ts file, rather than a .js file from the import condition.

[keithamus]

PRs welcome!

[jlarmstrongiv]

@keithamus would the PR include these changes?

• adding documentation to defaultRules
• editing the exports key to something like { key: 'exports', over: sortObjectBy(['types']) }
• patch version bump

Let me know if I missed anything in the outline 😄 if not, it should be a straightforward fix

[keithamus]

That’s correct. We use semantic versioning so prefixing your commit fix: will automatically apply and release the patch version.

[fisker]

If we are doing this, should we also enforce the default to be the last one?

[mrmckeb]

@keithamus are you still working on this? If not, I might pick it up.

[keithamus]

I am happy to accept PRs. I no longer contribute code to this repo as I prefer to let the community do so.

[mrmckeb]

Apologies, I meant to tag @jlarmstrongiv! I assume that this is not being worked on though?

[GeorgeTaveras1231]

I'll just add to this thread that types should not always be first. The order should be left up to the user of the library and by default, this package should avoid sorting imports and exports unless specified.

The reason types should not always go first is because package developers are free to define any arbitrary set of conditions. A developer may define a custom condition that takes precedence over the types one. For example, define a condition for using a different types file

{
  "exports": {
      "some-arbitrary-condition": {
        "types": "./different-types-file.d.ts"
      },
      "types": "./fallback-types-file.d.ts"
  }
}

[GeorgeTaveras1231]

@mrmckeb @jlarmstrongiv I opened a PR (#336) addressing this - Just thought I'd let you know, I didn't see your comments about potentially working on this before I opened the PR.

In my first comment I suggested not sorting unless specified - my PR takes a more opinionated position on sorting known conditions while leaving unknown conditions in place (mostly).

[mrmckeb]

Absolutely fine, this had fallen into my backlog - thank you, @GeorgeTaveras1231!