Is your proposal related to a problem?
I'm working on a codebase that will result in multiple similar deployed applications, but with small differences. At this point in time, only branding is different between the applications, but other differences will come over time. But they will share > 90% of the code base.
Describe the solution you'd like
By allowing you customize which entry point (i.e. 'index.js/index.ts') to use, I could have multiple entry points files:
// index.brand1.ts
import './styles/brand1.scss'
import './index.ts'
// index.brand.2.ts
import './styles.brand2.scss'
import './index.ts'
As more and more features are distinguished from the different brands, more responsibility of configuration and composition can be moved to the individual entry points.
Describe alternatives you've considered
Split the application into multiple codebases, sharing a common NPM package with all the reusable components
Although this approach my be the right approach in the future, at the moment it is overkill and will lead to too much complexity in the project setup.
Eject from CRA
The team isn't ready to maintain configuration of react, babel, eslint, tsc, etc. at this point in time.
Additional context
Our current solution is to have pre-build steps, that builds either brand1 or brand2's CSS files, and let the app reference the CSS output. That was the simplest solution that solves our need at the moment.
But this approach will become painful once we start to add differences in behaviour, as the codebase would probably become littered with if (process.env.BRAND_ID === "brand1") ...
Is your proposal related to a problem?
I'm working on a codebase that will result in multiple similar deployed applications, but with small differences. At this point in time, only branding is different between the applications, but other differences will come over time. But they will share > 90% of the code base.
Describe the solution you'd like
By allowing you customize which entry point (i.e. 'index.js/index.ts') to use, I could have multiple entry points files:
As more and more features are distinguished from the different brands, more responsibility of configuration and composition can be moved to the individual entry points.
Describe alternatives you've considered
Split the application into multiple codebases, sharing a common NPM package with all the reusable components
Although this approach my be the right approach in the future, at the moment it is overkill and will lead to too much complexity in the project setup.
Eject from CRA
The team isn't ready to maintain configuration of react, babel, eslint, tsc, etc. at this point in time.
Additional context
Our current solution is to have pre-build steps, that builds either brand1 or brand2's CSS files, and let the app reference the CSS output. That was the simplest solution that solves our need at the moment.
But this approach will become painful once we start to add differences in behaviour, as the codebase would probably become littered with
if (process.env.BRAND_ID === "brand1") ...