feat: allow importing sass/package.json

[AviVahl]

I'm trying to import { version as sassVersion } from 'sass/package.json'; and noticed it wasn't exposed in current "exports".

Current (1.63.6) package.json:

{
  "exports": {
    "types": "./types/index.d.ts",
    "node": { "require": "./sass.node.js", "default": "./sass.node.mjs" },
    "default": {
      "require": "./sass.default.cjs",
      "default": "./sass.default.js"
    }
  }
}

I wonder if it could be adjusted to:

{
  "exports": {
    "./package.json": "./package.json",
    ".": {
      "types": "./types/index.d.ts",
      "node": { "require": "./sass.node.js", "default": "./sass.node.mjs" },
      "default": {
        "require": "./sass.default.cjs",
        "default": "./sass.default.js"
      }
    }
  }
}

[nex3]

If you're trying to get the version, it's better to parse it from the info field, which is guaranteed to be set for all Sass implementations.

[AviVahl]

Not sure why I would want to parse the version from that string when the version is already available in the package.json, which my case is guaranteed to have. I'd also like to avoid evaluating the entire sass library just to get the version. Exposing the package.json is a pretty common practice, so I'd ask you to please reconcider.

[nex3]

The Sass package isn't just an API in itself, it's an interface that multiple implementations can implement. We want to be very clear what's an expected part of that interface, and exporting the entire package.json—most of which is fundamentally an implementation detail—risks having users over-index on the specific implementation they're testing against rather than the general shape of "a Sass API" that can be supported by multiple implementations. That's why we want to encourage users to go through the official, JS API.