search

kentcdodds / webpack-validator-DEPRECATED

Use this to save yourself some time when working on a webpack configuration.
MIT License
93 stars 8 forks source link

Monorepo #45

Closed jonathanglasmeyer closed 8 years ago

jonathanglasmeyer commented 8 years ago

Let's focus discussion about a monorepo approach started in #40 here.

https://github.com/kittens/lerna is the tool used by Babel to deploy / organize their repo. Should we use it? I think automatic releases are not possible with this tool, but I wonder how they'd be possible at all. The commit message doesn't tell us which package was changed, so it won't be possible to automatically derive the changelog from the commits.

kentcdodds commented 8 years ago

Hmmm... Without auto releases, I don't know whether it's worth having a monorepo... There are a few other things that make it less appealing. I think we can work around issues. Could we list the issues we're experiencing and see if we can find alternative solutions?

jonathanglasmeyer commented 8 years ago

Thinking this through helps :) Loosing auto-release is bad. Not so sure there are reasons that justify to give it up. Problems we are having without a monorepo:

More?

kentcdodds commented 8 years ago

Ok, so here are a few ways to address these things:

I think in general we need to remember that there probably wont be a ton of these kinds of plugins. Most loaders don't actually add anything/much to the webpack config. So we should consider that with our decision. Babel has a TON of plugins. We will have very few I think.

setup + infra overhead each time

We could copy/paste a lot of the setup and infra isn't too tough to set up. I'm thinking this is about an hour job per repo. Like I said, I don't think we'll need to have too many repos.

externalizing them could be seen as premature optimization.

Starting to think this may be true... I think that we should probably only externalize them when we feel the need.

Cross-cutting of concerns with configuration-validator.

Thinking about this now, I'm pretty confident that after this is finished, we wont have anymore issues with this. I think configuration-validator will be more-or-less done.

Also, I think that once we start getting things going, we can start making PRs to webpack plugins to add validators which I think would be the best way to deal with this. Hopefully the community will be accepting of this idea :-)

jonathanglasmeyer commented 8 years ago

I think that we should probably only externalize them when we feel the need.

This is combination with the fact that we probably won't have many convinces me that having seperate repos and packages is probably overkill at this stage. Maybe revisit this in 2 months and KISS at this point of time. The thing I didn't have in mind is that most loaders don't have obvious validation opportunities at all -- or should we parse query strings? :D Edit: on second thought, that would be pretty darn awesome, as those pesky query strings are arguably the place with most opportunities for subtle bugs.

kentcdodds commented 8 years ago

Agreed! That'd be way cool. Let's revisit this idea when/if things get unwieldy.