The 1.0 Experience - Share your feedback

[andywer]

Did you already try the v1.0.0-alpha? Please share any feedback with us! ♥️

Just leave a short comment like

• "Worked well"
• "Did not work, because ..."
• "Got it working, but documentation of ... is poor"

This will greatly help us locating possible pain points and improving the library.

Wondering what 1.0 is? Here is the new readme.

[dagatsoin]

Hello,
got it working, but documentation of basic assets managements (css/fonts/...) is not evident.

I am very new to bare Webpack configuration and Webpack-blocks is welcome. But I struggle too often on basic config.
Such as loading css (I though modules-css was for but just adding css() in createConfig works).
For now I am blocking on loading fonts #157.

BTW: this package is very welcome ❤️

[sapegin]

I have a few thoughts too, can elaborate on any of them:

• API is super nice in general, writing custom blocks is easy enough.
• Docs need improvements. Don’t know any ideas now unfortunately.
• Hard to understand what exactly blocks does.
• (Related to the previous) hard to find block sources, e.g., packages/postcss but packages/assests/lib/css.
• Composing different blocks isn’t obvious, especially styles.

[deckchairlabs]

Documentation is something I find lacking, a lot of the time you want to be able to dig a little deeper into a certain block, only to find a link back to the webpack-blocks repo readme.

[deckchairlabs]

If you need help with documentation, I would love to help out some way!

[andywer]

@TrajEdy Thanks for the feedback! Yes, documentation is still an issue...

If you have a suggestion how to improve the docs, feel free to open a PR. Help is always appreciated! :)

Btw, maybe you can tell us about a particular situation where the docs of a block you used where insufficient?

[deckchairlabs]

Shall open a PR soon!

[zcei]

Hej, got it working to 90%, but the last bits were tough.

I agree with the others that the documentation has its flaws - maybe I can find some time to document the stuff I stumbled across.

The use-case was to migrate the preact-boilerplate config to blocks, so that I can then start customizing to my needs.

First recommendation I have is a better assertion for createConfig. I forgot to wrap some webpack config in customConfig, and the error was quite useless to me, just stating that all array elements have to be functions. Outputing the first non-function element in the array would have speed-up the error discovery. (I had to cut the array out of the createConfig call and mapped its elements to their types)

The root cause for me not being able to migrate fully was the extractText block - it should reuse one plugin instance when invoked twice in loaders (like here). I tried a custom block workaround, but didn't work as expected and I will try to get my hands dirty with a PR.

Last but not least, there should be documentation that devServer implicitly adds HotModuleReplacementPlugin.
The boilerplate has a npm script that invokes webpack-dev-server with the --hot flag, resulting in a strange error that didn't imply the root cause (plugin defined twice). I eventually found the explanation in an issue

After all this "complaining" I want to say thank you for this effort! It was really straight forward to use overall - the custom blocks API is well-designed and the code was always concise & readable. I really hope to this project rising 🚀

[andywer]

Thanks for sharing, @zcei! I created a new issue (#171) for that.

Your feedback is very valuable and shall be addressed. It would be really cool if you could suggest documentation improvements :)

[TombolaShepless]

@andywer On the whole this project has been a joy to work with. It has made composing configurations so much easier, faster and tidier! That being said I have found one issue (not a big one!).

This PR is causing me some issues. We have resolve.extensions setup so that we can generate different bundles based on device types (e.g. mobile, tablet etc.). However because these two values appear first, Webpack will always resolve the "base" file rather than the override:

import foo from './foo' <--- If we have a foo.mobile file it will never be loaded.

Would it be safer to make no assumptions and have this as an empty array? Or is there an option/method I am missing? Prior to v1 we were using the create vanilla config approach but it looks like this has been removed?

[zcei]

@TombolaShepless I didn't want to hijack the feedback thread here, so I created an issue from your feedback to provide solution approaches.

[jvanbruegge]

I noticed a few issues:

• The extract-text block uses context.fileType and there is a deprecation warning about this
• Some 1.0 blocks (like tslint) use the LoaderOptionsPlugin, that should not be needed any more
• Uglifyjs block is not yet published, but already in the README
• I got a bunch of complaints about missing peer dependencies

[sapegin]

@jvanbruegge

Some 1.0 blocks (like tslint) use the LoaderOptionsPlugin, that should not be needed any more

It’s funny that we have tslint but no eslint in the core.

Uglifyjs block is not yet published, but already in the README

It was merged like yesterday ;-)

I got a bunch of complaints about missing peer dependencies

Could you open a new issue with more details? Or send a pull request if you know how to fix them ;-)