Private and public packages

[necolas]

Proposal to revisit the packages maintained in the monorepo. With these changes we should aim to resolve #888, #885, #788, #768, #809, #548, #476, #375, #363, #309, #297, #209, #172, #70 (20% of the open issues)

More "apps".

We can include more examples for tools that commonly turn up in support requests, for example, Vite. Everything in "apps" is a private package so we can iterate on them (with the community) without the same risk / requirements as work that goes on in packages that get published to npm. Once #908 lands, app builds won't slow down CI installs and testing of public packages so much.

• apps
  • docs
  • example-cli
  • example-esbuild
  • example-nextjs
  • example-rollup
  • example-vite
  • example-webpack

Fewer public "packages".

We maintain too many packages, of varying quality. StyleX having to maintain many separate bundler plugins, with limited adoption, is not sustainable. I suggest we remove them all. We have a postcss plugin that is currently recommended as the default setup. If reliable stylex bundler plugins could be provided easily and efficient by using "unplugin" (based on rollup API), that can be explored.

Then there is dev-runtime, which shouldn't be used by apps. Is there a compelling reason to keep that package around?

• packages
  • babel-plugin
  • benchmarks
  • cli
  • dev-runtime
  • esbuild-plugin
  • eslint-plugin
  • nextjs-plugin
  • open-props
  • postcss-plugin
  • rollup-plugin
  • scripts
  • shared
  • stylex
  • webpack-plugin

[nmn]

I agree with most of it except I'd like to continue maintaining the rollup plugin. It is a very stable implementation that hasn't given us much trouble and also serves as a good example for building community integrations.

The only other package worth maybe preserving is open-props. It's a bit outdated but it's only a prebuilt set of values, we can somewhat easily update it occasionally and maintain it with little investment.

I've been thinking about killing dev-runtime as it has had a fairly small amount of usage.
We should definitely discontinue the nextjs-plugin and probably also the webpack-plugin.

[necolas]

You could move the open-props package to your personal account if you want to keep working on it.

The rollup plugin has close-to-zero usage - https://www.npmjs.com/package/@stylexjs/rollup-plugin - but if unplugin really is based on the rollup api, maybe it can be transformed into an unplugin thing. Otherwise there's limited value in keeping one, low-use bundler plugin around

[nmn]

+1 on converting it to an unplugin package.

[nonzzz]

postcss-plugin is well and i think it's correct to make postcss-plugin as default integration. There is almost no need to consider the HMR problem under different bundle tools. I think the community can provide a high level integration based on postcss.

[predaytor]

but what about lightningcss? I thought it was much better than postcss in terms of performance and package size, not the ecosystem though.

[nonzzz]

@predaytor Sadly, AFAIK it's a strict CSS parser for lightningcss, i'm not sure if it possible to write a parser for lightning css.

[javascripter]

In terms of performance, web apps using StyleX won't benefit much from moving to lightningcss. Most time spent will be compiling and extracting source code using @stylexjs/babel-plugin, not processing raw.css like typical web apps (you only have one or two very small raw css files to process in StyleX apps).

[predaytor]

@javascripter yeah, it's not a big deal, but I wonder if there will be such an option in the future. lightningcss minification seems very impressive!

[nmn]

@predaytor If we use lightningcss it would be within the postcss plugin as our usage of postcss is a essentially a hack.