bem / webpack-bem-loader Goto Github PK

Example of bug: https://github.com/awinogradov/bem-react-core/compare/customizable...awinogradov:import?expand=1

Point: https://github.com/bem/webpack-bem-loader/blob/master/index.js#L117

How to solve:

if(main.block === ctx.block) {
  main.elem || (main.elem = ctx.elem);
}

Right now we have <i18n:param> for better localization.

and we use it like this:

{
 "myKey": "Some text <i18n:param>someParam</i18n:param>"
}

an in code:

import i18n from 'b:awesomeB t:i18n';

<input value={ i18n('mykey',  { someParam: 'wow' }) } >;

And it's cool
but what to do if we want to localize string with Component inside, or .

like:

import i18n from 'b:awesomeB t:i18n';

const button = (text) => (<button>{ text }</button>);

<span>{ i18n('myKeyInsideButton', { someParam: button }) }</span>

What syntax in keysets should we use?

my proposal:

{
"myKey": "... and then button: <i18n:wrap name='someParam'>Localized Btn-text</i18n:wrap>"
}

@veged any suggestions?

import MyBlock from 'b:MyBlock m:mod=val';

Now result with require of: MyBlock.js, MyBlock_mod.js and MyBlock_mod_val.js. But MyBlock_mod.js should be optional.

So, I can republish (bem-loader)[https://www.npmjs.com/package/bem-loader] with the different name, and we'll use bem-loader.bem option in webpack.config instead bemLoader and bem in the list of loaders instead of webpack-bem.

Зачем начали разработку нового лоадера, если есть bempack?
Может лучше его довести до ума?

It seems that it only supports js modules. How to use it with TypeScript?

https://github.com/bem/webpack-bem-loader/blob/master/index.js#L10

Now it works only by this way:

import * as Search from 'b:Search';

console.log(Search);

Because we transpile it to:

const Search = ((
(__webpack_require__(2).default || __webpack_require__(2)).applyDecls()
));

// ts use it like this
console.log(Search);

But! If we want use default export only:

import Search from 'b:Search';

console.log(Search);

const Search = ((
(__webpack_require__(2).default || __webpack_require__(2)).applyDecls()
));

// ts use it like this
console.log(Search.default); // .default -> undefined

We need to transpile it like this:

const Search = {
  default: ((
    (__webpack_require__(2).default || __webpack_require__(2)).applyDecls()
  ))
};

@bem -> @bem/sdk

    "@bem/cell": "^0.2.6",
    "@bem/entity-name": "^1.5.0",
    "@bem/fs-scheme": "^2.1.0",
    "@bem/import-notation": "^1.1.2",
    "@bem/naming": "^2.0.0-6",

https://github.com/bem/bem-sdk/pull/281/files

In 'loader-utils' version 1, parseQuery was deprecated

For example, we have such options:

                    options : {
                        levels : [
                            'common',
                            'project'
                        ],
                        techmap : {
                            js : ['ts', 'js']
                        }
                    }

and we have two files button.js and button.ts
first on level common second on project
right now we get:

   [(
require('./common/button/button.ts')).applyDecls()
    ),(
    (
require('./project/button/button.js')).applyDecls()
    )][0]

so we get only common button
but we want:

   [(
require('./common/button/button.ts'),
require('./project/button/button.js')).applyDecls()
    )][0]

to get full component

https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API

#42

It seems there are some troubles with path resolving on Windows
import BPage from 'b:b-page';

It will eat Win slashes and path to this block won't be resolved.

Example:
page__content.react.js

import 'b:page m:theme=normal';
...

--> { block: 'b-page', elem: 'content', modName: 'theme', modVal: 'normal' }

flex, flat, nested.

Relates to bem/bem-react#91

Failed to compile.

Error in ./src/index.js
Module not found: Can't resolve './common.blocksAppRouterAppRouter.js' in 'c:\work\<PROJECT_NAME>\src'

 @ multi ./~/react-dev-utils/webpackHotDevClient.js ./~/bem-react-scripts/config/polyfills.js ./src/index.js

import AppRouter from 'b:AppRouter';

It seems that b:blah-blah import missing slash on Windows.

Right now we work only with require:

if(!(
  node.type === 'CallExpression' &&
  node.callee.type === 'Identifier' &&
  node.callee.name === 'require' &&
  Object(node.arguments[0]).value
)) return;

we could process imports too.

https://github.com/webpack/webpack/releases/tag/v4.0.0-beta.0

When we have this:

• block
  • _mod
    • block_mod_val.css

Example: block with fonts.

react-create-app excepts only REACT_APP_* prefixed environment elements

For now we have code for emitting errors about non existent BEM modules.

In real projects it looks like infinite noise that does not help.
At the same time emitError requires a special as an argument as passing there a string generates Critical errors inside Webpack itself.

ERROR in ./blocks/block-a/block-a.react.js
(Emitted value instead of an instance of Error) BEM module not found: ../block-b/block-b.css
 @ ./blocks/block-a/block-a.examples/index.react.js 21:26-59 21:71-104

Actually, there are 2 cases that we should fix here:

• Create an error object instead of string to pass it in emitError
• Reduce count of errors (to a zero if possible)

folow up: bem/webpack-bem-i18n-loader#2
cc @iniel

For example, we have such options:

                    options : {
                        levels : [
                            'project'
                        ],
                        techmap : {
                            js : ['ts', 'js']
                        }
                    }

and we have two files button.js and button.ts both on level project
first on level common second on desktop
right now we get:

   [(
require('./project/button/button.ts')).applyDecls()
    ),(
    (
require('./project/button/button.js')).applyDecls()
    )][0]

we will get component that we want (button.ts) but we will applyDecls for button.js
it's wrong. In such case, we should use only one — js : ['ts', 'js'] the first one from the array of techMap.

• - i18n
• - techMap

Webpack 2 doesn't support custom fields in options.

Hi guys.

Let's say there is a following case:

├─ blocks
│ └─ Example
│ │ ├─ _mod1
│ │ │ └─ Example_mod1.css  /* styles #1 */
│ │ ├─ _mod2
│ │ │ └─ Example_mod2.css  /* styles #2 */
│ │ ├─ Example.css         /* styles #0 */
│ │ └─ Example.js
└─ app.js

/*   Example.js   */
...
import 'm:mod1';
export default decl({
  block: 'Example'
});

/*   app.js   */
...
import Example from 'b:Example m:mod2';
...

where mod1 is pretty lightweight and widely used (e.g. some disabled state with one-two loc), thus it's just easier to include it as a base block functionality (but still keep in a separate folder for clarity). Obviously, as mod1 overrides block's base styles, its css should be loaded after the main one.

With loader version <=0.5.1 loading order of styles was predictable & ok: 0 -> 2 -> 1.
But with 0.6.0 now it is 1 -> 0 -> 2 and totally breaks existing logic, described above.

If you try to import element in block import 'e:Elem' from block's modifier you'll see this:

Module build failed: Error: This is not valid BEM entity: the field `block` is undefined.

check https://github.com/bem/bem-sdk/tree/master/packages/config#config-example

Link to 'naming' leads to almost empty page.

Also RFC for

                // levels: {
                //     './pathToBlocks': {
                //         default: true,
                //         scheme: 'nested',
                //         naming: 'origin'
                //     }
                // },

Default? Scheme? Naming?

Thank you.