feature / improvement request to check for BEMIT and more

[gael-boyenval]

Hi, this was initially posted as an issue in stylelint repo.

Feature : a customizable BEMIT selector syntax checker

the BEM linter is great but it doesn't allow to customize enough to enforce BEMIT @csswizardry (Harry Roberts) proposal.

a great article about BEMIT here or for the lazy ones : BEMIT Cheatsheet

it's about namespaced BEM selectors, and enforce different rules for those deferents types.

some of the BEMIT types:

• scope .s-
• themes .t-
• components .c-
• states .is- | .has- | .no- ...

some "types" can be combined :
.c-component.is-open => ok

but others not :
.c-component-a .c-component-b => warn

implementing a strict ruleset would be great but being able to configure it and create our own would be even better :

{
    // basic syntax checker, create your own flavor of BEM if you want
    generalSyntax: {
        wordDelimiterStyle: 'lowerCamelCase' | 'CamelCase'  | 'snake_case' | 'kebab-case' | 'min' | 'CAPS',
        modifierDelimiter: '__' | regex,
        elementDelimiter: '__' | regex
    },
    registerTypes: [
        {
            name: 'components', // the name of the type
            namespaces: .c-|.custom-|.other-|, // a regex to match namespaces,
            canCallClassType: ['states'] | 'any', // array of registred types that can be called in a selector`.c-popup.is-open`
            allowHostDiferentBlock: false // disalow `.c-carousel__nav .c-btn`
        },{
            name: 'states',
            namespaces: .is-|.has-|.no-|,
            canCallClassType: 'any',
        },{
            name: 'utilities',
            namespaces: /.is-|.has-|.no-|/ regex,
            canCallClassType: ['registredName'] | 'any' | 'none',
        },{
            name: 'themes',
            namespaces: /.t-/ regex,
            canCallClassType: 'any', // allow '.t-dark .c-btn--alert' selector
        },{
            name: 'scopes',
            namespaces: /.t-/ regex,
            canCallClassType: 'any',
        }
        ...
    ]
}

each selectors would be evaluated, the first class would be considered has the "host" and all other has "hosted" :

exemple :

with the given registered types :

      {
            name: 'components',
            namespaces: 'c-',
            canCallClassType: ['states'],
            allowHostDiferentBlock: false
        },{
            name: 'states',
            namespaces: 'is-|has-|no-',
            canCallClassType: any,
            allowHostDiferentBlock: true
        },{
            name: 'hacks',
            namespaces: '_',
            canCallClassType: any,
            allowHostDiferentBlock: true
        }
...

lint results :

.c-slider__nav .c-btn {} 
/* warn 'a component cannot host another component' */
.c-popup.is-open {} 
/* good */
.c-popup .anyothernamespace-anyblockname {} 
/* warn 'this element should have a registered type/namespace' */
/* warn 'a component cannot host  anyothernamespace' */
.x-block {} 
/* warn 'this element should have a registered type/namespace' */
._hack .someExternalComponent {} 
/* good */

there is obviously many uses case that are not taken in account here, and the naming conventions that I used is certainly not the best, but you get the spirit…

I'm not very confident that you would agree to change so much of your plugin's philosophy to match those requirements, but I was wondering about forking your repo and maybe build on top of what's have already been accomplished here.

It would be very nice of you to point me to the right direction. :)

Maybe some peoples would be interested to work with me on that to.

cheers :)

GB

[simonsmith]

Hi @gael-boyenval,

I like the idea that you have here but I wonder if the amount of effort needed to implement it would outweigh the benefits. Apart from BEMIT are there that many other implementations of BEM being used that people would want to implement as a configuration such as this?

It might be simpler to look into adding BEMIT as a proper preset alongside SUIT and the traditional BEM. If more and more users opened issues for different flavours of BEM (that the current customisation options cannot fulfill) then maybe it would be time to consider overhauling the API.

What do you think?

[gael-boyenval]

Hi @simonsmith, yes I completely understand. Adding the preset would be a great thing.

Personally, I want to give it a more complete approach by the ability to forbid .type-a .type-b patterns (is bem linter already implementing that ?), and analyse more deeply the composition of the selector, not only the class syntax.

The other part of creating prefixed class is that it create a sort of "typed css" approach. This could allow to apply different rules to each types.

Also, I'm implementing another approach. Something based on ITCSS, but not exactly. I would love to see a plugin that allow users to have complete control over this, through configuration.

I completely understand that it would be big rewriting of postcss-bem-linter and changing so much of the core concepts would be complicated.

So, I'm already taking the firsts steps to build a Stylelint Plugin. I may post here the link to the repo. I would be glad that you agree to participate, guide me a bit or code review me in this effort, because it doesn't look like very documented and the learning curve seem pretty steep to me ;)

I have some difficulties to harness the full potential of postcss and stylelint built-in capabilities, due to a lack of comprehensive documentation.

Thank's for your answer, and your time. I hope we will discuss the subject again.

GB

[diegosantamarta]

Hi Gael, did you finally worked on this? How are you doing it right now?

[gael-boyenval]

@diegosantamarta I've started something, but it's a wile ago and I have been carried away by other projects. Would you be interested to work on it with me ? I currently have a project that could use this !