Add tsd about webpack-blocks HOT 7 OPEN

Another term that might be discussable is WebpackBlockUpdater (see PR #247).

Maybe it's rather a WebpackConfigUpdater: It's actually so generic that it's not webpack-blocks-specific. And this name might transport more information. Objections?

from webpack-blocks.

We need to discuss terminology here, since most terms haven't ever been clearly defined.
Current state of affairs is:

Initially I was thinking that a block is a self-contained, configurable portion of a Webpack Configuration - so actually entryPoint is the block, not entryPoint(), which could be a BlockInstance or similar.

Then a block is everything that has the signature (...args: any[]): BlockInstance, where BlockInstance = (current) WebpackBlock

If someone has a better naming suggestion for BlockInstance, feel free to share it here 😉

from webpack-blocks.

Suggestion for terminology, based on @zcei's PR:

• entryPoint, for instance, is the Block
• entryPoint() could be called a BlockInstance
• WebpackConfig should be self-describing
• WebpackConfigUpdater describes a function (prevConfig: WebpackConfig) => WebpackConfig

Note that I called it Block, not WebpackBlock, but yet called it WebpackConfig (not Config).

Idea behind it: There is no other "block" concept here than the lib's webpack blocks, so there might not be a need to make the name long. "config" on the other hand is such a general term that it might be better to call it "webpack config" when we talk about it.

Feel free to disagree now 👇

from webpack-blocks.

On a second thought we could also "invert" the meaning, with:

• entryPoint being a BlockCreator
• entryPoint() being the Block

But I'm not too sure about it. Currently going with your approach - if necessary it's a matter of a simple "Rename symbol" refactoring.

from webpack-blocks.

Fair enough. Feel free to open a PR if it‘s an urgent issue 😉

from webpack-blocks.

WebpackConfigUpdater is way better indeed. As it's just (previousConfig: WebpackConfig): WebpackConfig it really just is an updater for any Webpack config

from webpack-blocks.

I just pushed some changes to the PR (#247), where I went with my proposal from last post.

In fact we never specify entryPoint types, they all just inherently comply to the Block / BlockCreator interface, as they all return an instance.

So the term Block belongs to the instance (entryPoint()) for me, as it will way more often be used than the creator interface.

Everyone who'll be talking in issues about "a bug in the block" will talk about a specific configuration, so basically there's a bug in the instance of the created block.

As @andywer said:

Feel free to disagree now 👇

from webpack-blocks.