fix(plugin): add root export entry for steiger plugin

[yslpn]

Fix package root exports for @feature-sliced/steiger-plugin.

Closes #225

[changeset-bot]

🦋 Changeset detected

Latest commit: 4113662

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@feature-sliced/steiger-plugin	Patch
steiger	Patch
@steiger/integration-tests	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Solant]

The current conditional export is valid, as per https://nodejs.org/api/packages.html#conditional-exports

It also properly resolves locally, so I don't think we need this change.

[illright]

Does this change actually solve the problem in that issue, btw? Didn't try myself yet, just wondering

[Solant]

@illright I checked it myself; the problem in the referenced issue is due to pnpm hoisting, not conditional export.

The current conditional export works correctly.

[illright]

Yeah, but pnpm is the industry standard now, and package isolation is one of its central selling points, if it doesn't work with pnpm out of the box, then it's an issue on our side

[Solant]

In this case we need to remove @feature-sliced/steiger-plugin from the steiger package.json dependency and install it alongside steiger during initial setup, like pnpm add -D steiger @feature-sliced/steiger-plugin, and then create an initial config file like this:

import { defineConfig } from 'steiger'
import fsd from '@feature-sliced/steiger-plugin'

export default defineConfig([
  ...fsd.configs.recommended,
])

Because the current zero-config approach relies heavily on hoisting (which is disabled by default in pnpm). I think we can do some auto resolutions in steiger to omit the initial config requirement, though.

It looks like you tried to do something like that in #197

[illright]

Because the current zero-config approach relies heavily on hoisting (which is disabled by default in pnpm).

If it's your direct dependency, then pnpm will put it on the top level of node_modules, so the zero-config approach is still perfectly compatible with pnpm. It will break if, say, someone only installs steiger and not @feature-sliced/steiger-plugin

[Solant]

Ah, yes, we have a @feature-sliced/steiger-plugin as part of the installation process. All good then 😄

But I still don't think we need this export change

[yslpn]

The current conditional export is valid, as per https://nodejs.org/api/packages.html#conditional-exports

It also properly resolves locally, so I don't think we need this change.

@Solant Thanks for review. I think you're right. The reason I decided to make this change is because I looked at all the exports for the monorepo, and they all use

  "exports": {
    ".": {

I wanted to make it consistent and fix the problem of cource.

In any case, we can close the issue and PR.

[illright]

Let's wait with closing until we hear from the issue author :)