andywer / andywer/webpack-blocks

@easy-webpack: Same idea, similar execution

Aberta
#103 3 comentários 0 reações 0 responsáveis Ver no GitHub
discussion
Linguagem predominante
JavaScript
Estrelas
3k
Forks
91
Métricas de merge de PRs
Nenhum PR com merge em 30d

Descrição

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?

Guia de contribuição

Abrir o guia de contribuição

Avaliação

Esta issue ainda não foi avaliada.

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.