Vitaly
Vitaly
_Firstly_. If level is not equal to layer why do we write in `.bemrc`: ```js { levels: [{ layer: 'desktop' }], // levels item is layer not level ? //...
Its also needed for `method('b:foo e:x e:y')` and `method('b:foo e:y e:x')` to return same result independent from initial order (of elements/modifiers/techs/etc-if-any)
> are you sure it should be the same order? not really. In plugin I want notation-string to be unique. In general it is not required > Can you collaborate...
@zxqfox suggests "extends"
I need some extra effort here @tadatuta
I agree referencing specific layer is kind of hack. Lets close it and fix `README.md`: > // Will use `touch-phone` set from bem-components and few local levels > "touch-phone": "@bem-components/touch-phone...
@tadatuta lets finish this :)
@tadatuta tells me that `path` property can directly point to custom path. Like: ```js { levels: [{ layer: 'common', path: 'blocks' }], sets: { common: 'common' } } ```
This approach will fail when _BemCell_ will be [stringified with preset](https://github.com/bem/bem-sdk/blob/master/packages/naming.presets/origin.js#L10). We will get something like "blocks/common.blocks". Besides level defined with [path property is deprecated](https://github.com/bem/bem-sdk/pull/284/files#diff-621cc23937ce7f99fed2fab23dbbbee0R38)
1. @veged sends me in this direction (actually wrong one). _Our_ projects should use _another library_ I understand that now. We've planned to migrate from "bem-react-components" 2. Hmm "defaultLayer" seems...