0

I have a script a generic script. It runs on one website, now we start to put it on other websites but it requires customization. Most elements of the script stays the same between versions.

Right now I have branches with different versions but it isn't scalable.

I can change the script so the moving parts are enclosed as interface and then provide implementations for each website as a separate file / class.

I would like to configure the build script (right now it's webpack) so I can run:

npm run build --impl ExampleComImpl

I'm not stuck with webpack and can migrate. Main reason for using webpack is it's ability to pack all resources as one file.

Paweł Szczur
  • 5,484
  • 3
  • 29
  • 32
  • 2
    I have an exact scenario where I have N different projects that have some customisations but shares almost the same codebase. To solve the task, I've defined some .json files having a "configuration" that is read by webpack at compile-time. This configuration is also available at runtime, so that if some modules are enabled or disabled, the code is aware of that. Not sure whether that's what you're looking for, but it's still worth commenting about an idea. – briosheje May 13 '19 at 10:25
  • This is similar case, but I must provide one self-contained script for the website to load therefore I don't want to put all modules in this script. Do you do compile-time selection of classes? – Paweł Szczur May 13 '19 at 10:41
  • 1
    In my case it's an angular application: because modules are all lazy-loaded, I don't need to deal with compile-time selection of classes, I just make a unique bundle and include / exclude specific folders according to the config. However, the build size of the application doesn't really change "that" much, most of it is done by third party libraries (angular, rxjs...) so, overall, I just happen to exclude some folders and set several environment variables. In a nutshell, my webpack compilation is most about setting configurations and copying assets, but you can use it to exclude code as well. – briosheje May 13 '19 at 11:32
  • 1
    I think you should analize how many files and folders are shared across the project. Once you did that, you can think about either making a module with the shared content and build the single projects, either decide to have a unique codebase and serve different builds (using different build configurations as mentioned above) or if you want to simply serve a single, unique, build and enable / disable features according to a build configuration. If you care about the bundle size, you should build up the project excluding the folders you don't need, and you may do that with a configuration file. – briosheje May 13 '19 at 11:35
  • 1
    I'm going to try using `webpack --env.site ` and do some dependency injection, it's similar to: https://stackoverflow.com/questions/28572380/conditional-build-based-on-environment-using-webpack – Paweł Szczur May 13 '19 at 11:35
  • 1
    Yup, that's definitely a good way to go. You may try different approaches and pick the one which is more suitable for you. In any case, it largely depends, in my opinion, on the type of application you're serving: some frameworks, like angular, already take care of that and the bundle size doesn't really change that much, unless you include tons of assets. – briosheje May 13 '19 at 11:38

0 Answers0