Externalize postcss validator into own package

[jonathanglasmeyer]

As discussed in #20, i extracted postcss loader into an own package.

So right now the user would have to explicitly install the validator plugin and set it up themselves. Automation & install hints etc. are still a todo.

Stuff I'm not 100% sure about: how should dep versions of the "blessed" externalized validators be handled? Wildcard? Pinned?

[kentcdodds]

how should dep versions of the "blessed" externalized validators be handled? Wildcard? Pinned?

I think let's do range with ^... Thoughts? :thought_balloon:

[kentcdodds]

So right now the user would have to explicitly install the validator plugin and set it up themselves. Automation & install hints etc. are still a todo.

I think that's fine for now :+1:

[jonathanglasmeyer]

It'd awesome to autoupdate them with greenkeeper, no need to think about this at all then. :)

[xjamundx]

What about that monorepo architecture? Something to consider here...

On Sat, Mar 19, 2016 at 10:17 AM Jonathan Werner notifications@github.com wrote:

It'd awesome to autoupdate them with greenkeeper, no need to think about this at all then. :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/kentcdodds/webpack-validator/pull/40#issuecomment-198750997

[jonathanglasmeyer]

Looking at babel repo structure, core packages are in one repo. Third party plugins are in own repos, though. Same for eslint. This is good in the long run as it decreases burden of core maintainers to handle issues of third parties. It also gives plugin authors autonomy in code style preferences and testing framework.

[xjamundx]

My opinion is that external plugins is a last resort

On Sat, Mar 19, 2016 at 10:24 AM Jonathan Werner notifications@github.com wrote:

Looking at babel repo structure, core packages are in one repo. Third party plugins in own repos, though. Same for eslint.

— You are receiving this because you commented.

Reply to this email directly or view it on GitHub https://github.com/kentcdodds/webpack-validator/pull/40#issuecomment-198752571

[jonathanglasmeyer]

Could you elaborate? My impression is that eslint-plugin-* and babel-plugin-* architectures have enabled the growth of ecosystems for those tools.

The only disadvantage Babel 6 had was exposing to much choice to end users. You def need curation for such architectures, i.e presets or builtins.

[kentcdodds]

I think Jamund would prefer that this has all validators built in?

[jonathanglasmeyer]

I got that, but would be interested in the why, taking into account the stuff discussed in #17 and #20.

[kentcdodds]

What about that monorepo architecture? Something to consider here...

I like that idea. We're already experiencing cross-cutting concerns between configuration-validator and webpack-validator. It'd be nice to have at least those two in this same repo. And putting plugins in like babel has done would probably be handy too for tooling and integration testing.

[jonathanglasmeyer]

We're using a monorepo at work. Its awesome, really leveled up our productivity. I'm still wondering what's the best approach for plugins? Do we want to model them as external plugins (although they can be in the same repo) or do we want to handle them just like the core validators?

[kentcdodds]

The only problem I have with including them automatically is it makes it difficult for someone to turn them off if they don't want them. I'm not worried about perf or anything else. We can include hundreds (tens of thousands?) of these validators before we'll notice any slowdown.

So if we can solve the problem of how to disable validators then I say we're fine to make everything included by default.

That doesn't mean that we include them in the core library though. If we did that then we'd be releasing the entire lib every time any validator has a change and I don't want to do that. I'd rather have these each be separate modules that can be updated on their own and then the core lib can reference them as dependencies with a minor patch range.

Thoughts?

[sarbbottam]

What about that monorepo architecture? Something to consider here...

I like that idea. We're already experiencing cross-cutting concerns between configuration-validator and webpack-validator. It'd be nice to have at least those two in this same repo.

My :dollar: 0.02

• Monorepo is more productive and time effective, when the project in its initial phase and with limited contributors.
• Splitting functionality into its own module at the beginning of the project, might have productivity concerns, for example carrying it similar chores/fix in multiple modules.
• However, as the functionality/code & contributors increases, monorepo impacts productivity.
  • think about multiple contributors working on a similar problem
  • time being spent in resolving merge conflicts, which is bound to arise
• Monorepo lacks modularity, separation of concerns and reusability
• From my experience, I have noticed that few contributors become SPOF in some areas and any failure there, creates a bottle neck, however if they would have been a dependency, switching to a know stable version is super easy.

I would request everyone, to kindly think through the above point and may be some more, before combining or splitting functionalities.

Thanks!

[jonathanglasmeyer]

I think the success of Babels and even face books monorepo approach shows that it's productive doesn't decline with count of contributors. :) Monorepo doesn't imply one package --> modularity isn't necessarily impacted.

I'm wondering how commitizen/automatic releases work with multiple packages in one repo?

[sarbbottam]

Monorepo doesn't imply one package --> modularity isn't necessarily impacted.

Thanks for enlightening, I have been to ignorant to realize that :worried: My arguments are not valid with this respect.

BTW, I am :heart:ing open source, learnt so much, in past two days.

Quick :question:, how is the CI setup, per package or per repo?

[jonathanglasmeyer]

@kentcdodds I think your suggestions are sensible. Disabling should be a straight forward implementation. Totally subscribe to your last paragraph. Let's do it like this. Monorepo with external validators as own packages required as dependencies from core.

[jonathanglasmeyer]

Will close this and revisit this when we have a monorepo.