feature request: support conditional exports (package.json `exports` field)

[ctjlewis]

Love the style support, but would really helpful for conditional exports to also be legible to postcss-import:

{
  ...,
  "exports": {
    ".": "./dist/index.js",
    "./*": "./dist/lib/*/index.js",
    "./styles": "./dist/styles/index.css",
    "./styles/*": "./dist/styles/*/index.css",
    "./package.json": "./package.json"
  },
  ...,
}

The main reason I suggest this is because I cannot specify an @import "my-package/styles" statement in a way that is supported by both esbuild (supports standardized package.json exports, but not nonstandard style) and postcss-import (where situation is reversed). my-package/styles is the only thing that works for esbuild, but my-package is the only thing that works for postcss-import.

I would recommend following the Node doctrine of "if exports exists, it overrides anything else" (i.e. style field). Also thank you for maintaining this project, it is a core part of modern development workflows IMO, only reason I suggest the enhancement.

[RyanZim]

The module we use for resolution doesn't support exports yet; so that's a technical blocker: browserify/resolve#222.

Presumably, we'd want to support some kind of style-specific conditional export as well, so you could export both JS and CSS at ., similiar to how using both main & style works today. Does esbuild have anything like this?

[ctjlewis]

No sir, not that I know of, hence the conflict.

Regarding "JS and CSS at same import", I would not recommend that! You can import from "." with postcss-import by using the nonstandard "style" field; to use exports, you must pick one.

Pure CSS modules could export at ".", and normal JS modules could simply export at "/styles" (which is what I do).

/* NBD! */
@import "my-package/styles"

[davidwebca]

I was also looking for this just now. I assumed it would be finding exports (example of how the popular slider component Swiper does it: https://github.com/nolimits4web/swiper/blob/e54f07d6047f56e0469fd7d3024ede36e5b942fe/src/copy/package.json)

[ctjlewis]

Ideally the identifier would just be run through native Node resolution to get the entry point and prefer the style field in nearest package.json (else fall back to entry point at .).

This way the specifiers are "true to form", and @import "..." mirrors import(...) in JS as closely as possible.

[RyanZim]

Relevant: https://nodejs.org/api/packages.html#community-conditions-definitions

[romainmenke]

Also relevant : nodejs/node#46994

[samhh]

This can surely be improved upon, but it was enough to have postcss-import find self-referenced subpath exports (style condition) in the repo I'm working on:

  resolve: async (id, baseDir) => {
    const manifest = await readPackageUp({ cwd: baseDir });
    if (manifest === undefined) {
      throw new Error(`Failed to find manifest for "${baseDir}"`);
    }

    const resolved = resolve(manifest.packageJson, id, {
      conditions: ['style'],
    });
    if (resolved === undefined) {
      throw new Error(
        `Failed to find subpath import or export pattern matching "${id}"`,
      );
    }

    const [relative, ...rest] = resolved;
    if (relative === undefined) {
      throw new Error(
        `Failed to find subpath import or export pattern matching "${id}"`,
      );
    }
    if (rest.length > 0) {
      throw new Error(
        `Found multiple subpath import or export patterns matching "${id}"`,
      );
    }

    const absolute = new URL(relative, `file://${manifest.path}`).pathname;

    // The above will build a relative and then an absolute URL for any
    // import pattern, regardless of whether or not it's compatible with the
    // manifest (e.g. manifest name "foo" and absolute import from "bar").
    // We'll workaround this in a slightly hacky way by just checking if the
    // resolved path exists or not. This isn't airtight but we're unlikely
    // to hit a false positive.
    if (!fs.existsSync(absolute)) return id;

    return absolute;
  },

Uses read-package-up and resolve.exports.

[RyanZim]

Since browserify/resolve#222 is slow to be resolved, we could potentially look at switching to https://github.com/webpack/enhanced-resolve

[stretchkennedy]

I've been struggling to get BlockNote CSS imports working for a couple of days. I ended up using this package, with the following postcss.config.mjs:

import er from 'enhanced-resolve'

const resolveId = er.create({
  conditionNames: ['import'],
})

export default {
  plugins: {
    // ... other plugins ...
    'postcss-import': {
      resolve: (id, base) => {
        return new Promise((resolve, reject) => {
          resolveId(base, id, (err, result) => {
            if (err) {
              reject(err)
            } else {
              resolve(result)
            }
          })
        })
      },
    },
    // ... other plugins ...
  },
};

I'm leaving this here in case anyone else wants to swap to enhanced-resolve. The important thing to note is that you must specify an appropriate list of conditionNames when creating the resolver if you want to resolve packages which use conditional exports, which was the case with BlockNote.

[hiSandog]

If conditional exports are added, the expected condition order should be specified explicitly. CSS packages may expose style, sass, default, or environment-specific branches, and mirroring Node's JS resolution too closely could pick a JS entry when a stylesheet entry exists. A small fixture package with exports branches for style, default, and a subpath would make the intended CSS-first behavior unambiguous.