andywer / andywer/webpack-blocks

@easy-webpack: Same idea, similar execution

Abierto
#103 3 comentarios 0 reacciones 0 asignados Ver en GitHub
discussion
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

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.