andywer / andywer/webpack-blocks
@easy-webpack: Same idea, similar execution
- Lenguaje dominante
- JavaScript
- Estrellas
- 3k
- Forks
- 91
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Descripción
Hi @andywer,
I'm the author of [easy-webpack](https://github.com/easy-webpack/core), which, from the looks of it seems like the same idea as `webpack-blocks`, just executed by a different person. Am I correct in assuming you weren't aware of my project in July 2016 and thus started your own, or was there something about @easy-webpack that didn't satisfy your needs?
Looking through your project I saw some overlapping issues between our projects: the latest design of @easy-webpack uses a different solution to the ones proposed in https://github.com/andywer/webpack-blocks/issues/34, I've been struggling with the 'best design' for this myself.
Being the default configurator for the @Aurelia framework, we also had some user complaints about how 'blackboxed' the configs are (i.e. it takes an effort to take them out when you reach a point a 'preset' is not enough; I imagine it's the same with `webpack-blocks`), so I had some thoughts on how to mitigate this for v3 of @easy-webpack by simply inlining the generated configs with a sort of virtual 'git' repository, marking edges of inlined presets in comments. I've also recently thought of a different concept for conditional configuration, [like this](https://github.com/aurelia/skeleton-navigation/blob/0d67c8224099d54a08ee4a5a9c5a9b1047abe2ef/skeleton-typescript-webpack-experimental/webpack.config.ts#L74), but I'm still thinking about the best way to solve both of these.
Would combining efforts make sense to you?
Guía de contribución
Evaluación
Este issue todavía no se ha evaluado.