As a developer I would like the option to add custom webpack rules to be compiled

[themoch]

It would be nice to have the ability to add custom rules without effecting the base build and modifying the webpackConfigurator.js to meet specific needs of a project.

Proposition

• Add a custom config file to OC root that outlines custom rules
• in package.json configure the location of config file (not in package.json because it should be able to take vars)
• in oc-template-react-compiler make check for config file, if there use it, if not ignore
• require users to include webpackLoaders as part of their devDependencies so that they can configure things themselves.

[nickbalestra]

Thanks for this!
The reason why we stayed away from that till now is to keep some-kind of control on how things published on the registry get compiled. The idea of templates is also that you can easily fork/build your own and whitelist it in the registry.

On the other hand I like the idea an we discussed something similar a couple of times, to better understand your scenario could you provide some specific use-case of what you would like to alter in the webpack rules?

[themoch]

sure,

• If I wanted to include a specific post-css loader that is not currently handled, I could/should be allowed to do so without impacting other developers.
• If I wanted to, for some reason, include SASS I should be allowed to do so
• I feel like the use cases are limitless

[nickbalestra]

As an option, what hold you from creating your own template to support all the needed cases for your developers?

[themoch]

It prevents a developer from having to maintain a custom oc-template and insure that it is up to date with base while allowing flexibility in configuration.

If a user wants to use oc-template-react but wants to use an extra post-css plugin, I don't see why there should be a need to either add that as part of oc-template-react or make the user fork and create a whole new oc-template just for one plugin.

There SHOULD be a bass template, just maybe make it accept some flexible params.

[themoch]

I've created a PR here: #162

I would appreciate feedback 😃

[nickbalestra]

Just an heads up: as @kmcrawford mistakenly merged #162 and reverted afterward, there is not a PR for this anymore. I'm ok with that as I would like to discuss this further before we attempt a PR.

[matteofigus]

I have to agree with @nickbalestra here.
The goal of the template is to have baked opinions so that registry maintainer and component owners have a contract for how the components will look and behave like. This is also useful because we kind of know that many OCs in the same page will behave nicely with each other.
In fact, the registry owner has to whitelist all the templates for that reason.

Opening up to customisations on the component level is very risky but I see why you may want to do it. Let's take the PostCSS example.
If you want to allow PostCSS or Sass, wouldn't you want all the components of your registry to follow the same convention? It allows standardisation and also adds some form of guarantee that when multiple components will be in the same page, they will more likely behave nicely (no CSS conflicts for instance, etc.)
This is actually one of the very reason we switched from the easy and simple unopinionated base templates (where in 3 years of production and dozens of devs, we observed an explosion of diversity in terms of tech choices - too many perhaps) to the templating system.

Now, that said, if you want to allow the template you use in your registry to do this, I think you should, and that would just need to be a fork and a publish to npm as a different name.

Just my 2 cents... 🙏