Open MLoughry opened 1 year ago
I see that the
@griffel/babel-preset
depends on@linaria
, which in turn has mechanisms to runstylelint
over the resulting CSS. However, I cannot seem to get it working with Griffel.
Currently we use just a part of Linaria that performs module evaluation, in background we are trying to move to v4 (#414), but there are still blockers that prevent us from its adoption 😿
Fair note: we actively collaborate with Linaria maintainer to resolve them.
Is there already an undocumented way of doing this that could be documented? Or would it be possible to create a supported way to do this?
There is no way to do this currently, however @ling1726 works on enhanced ESLint rule/plugin that runs against compiled CSS. The benefit of this approach that we can emit errors on source code and don't require build for a feedback loop that makes DX significantly better 💪
I think that it would be great to embed stylelint
to these changes. We don't have it in opensource yet, but I will connect you in offline.
Needs some investigation to see if we can implement a stylelint preprocessor for Griffel and get good source mapping support. It's essentially all that Linaria's stylelint package does https://github.com/callstack/linaria/blob/master/packages/stylelint/src/preprocessor.ts
The current work with eslint, does much of the same as a stylelint preprocessor would require - we'd just need to see if we need to do that work differently with stylelint
This is somewhat high priority for Loop. We really need linting for our CSS because our developers are using various too-new CSS features and not testing in older browsers nor testing for all themes we support.
I see that the
@griffel/babel-preset
depends on@linaria
, which in turn has mechanisms to runstylelint
over the resulting CSS. However, I cannot seem to get it working with Griffel.Is there already an undocumented way of doing this that could be documented? Or would it be possible to create a supported way to do this? We already have a number of
stylelint
rules that we would like to re-use after a migration without having to rewrite them as questionable ESLint rules.