Modularizing legacy frontend application to include licensed modules

I've recently started working on a legacy frontend application (pre ES6, jQuery). There is no framework in place and no plans of implementing one in the near future. I am looking to modernize the codebase with ES6 features, including ES6 modules, however there is a sticky issue for me in that some of the potential modules are ones which will become licensed in the future. So basically, there will be a core app and some extra modules which can be bought separately.

All of this is in the future (the backend is not ready) but I would imagine the frontend will receive a list of available modules that the customer has paid for and these can be loaded along with the core app.

My question is more of a design pattern question with regards to the approach I should take. For example, in the current application and in what will be the core application, there is a global settings page. Some of the settings are for features which will only be part of a paid extra (i.e. licensed module). If the application is started with no extra modules, those settings should not be available, and vice-versa. I'm new to software architecture, but I would have thought that the core application should not need to know about extra module.

As regards to a solution, I was thinking about something like a registry of modules which would be populated based on what has been provided from the backend. (i.e., what the customer has paid for). I can then use this registry to add extra settings to the global settings page, but I'm kinda lost about whether this is a good approach. I'm basically wondering if there is some kind of common design pattern for this kind of thing?