Hello, looking at , modules

UPWG9AYH2

Hello,
looking at https://github.com/spryker-shop/b2c-demo-shop/blob/master/composer.json, modules are pulled via feature packages. But also the single modules are specified again. For example spryker-feature/tax which is fetching spryker/tax-storage:^1.20 … why is this package also explicit pointed out again in the composer file itself? Its exactly the same value as in the feature meta package in that case 🤔

Valerii Trots

Could be a mistake.
cc @UT9PVABFB

Andrew Chekanov

@UPKAYJJ2U please take a look

UPWG9AYH2

Okay so might be a lucky finding^^ … generally, all modules not wrapped in features are for example suggested extensions to that features?

UPWG9AYH2

or why do i need to point out single modules at all?

Valerii Trots

In general our demo shops are using spryker-features and there is no need to use single packages that are included into features already.

Dmitriy Krainiy

Having this module on project level is a mistake, same as some other modules.
We will fix it in next release.

In general, on project level we include GLUE modules, Connector modules and modules that were not included in feature repository.

Eugenia Poidenko

You need to require module only when it is not a default requirement: eg connector modules or rest api - they are not in feature’s require section in composer.

UPWG9AYH2

so best would be to use feature packages and extend by single modules like api modules

UPWG9AYH2

and for the suite example? There are ONLY modules and not any feature packages … thats just for showcase purpose since not every module may appear in a feature, correct?

Valerii Trots

Suite is following daily updates. And we don't update features as often as we update modules.

Features are updated like b2c\b2b demoshops - just couple of times per year.

UPWG9AYH2

okay that makes sense. so we currently try to find a way for a project start phase with a (mostly) limited feature set. since the suite is always up to date, it seems a good entry point, but it also means very much effort to remove all the stuff that we don’t need … is there any prefered method to start with that? We know, b2c/b2b demo shops might be a start but they might not up to date to the very latest changes

Valerii Trots

Current releases of b2b\b2c demo shops (202009.0) are couple of weeks old.

So for now it would be easier to start there and remove not needed features.

But if the project will start, let's say, in couple of months from now, it's still can be easier to start there, remove not needed features and split remained ones to update them to newest state.

Because anyway you will need to solve the question on how to update features in the future. And unfortunately AFAIK we don't provide migration guides for features, only for modules. So you will need to split a feature to modules anyway in such a case.

Jeremy Fourna

@valerii.trots the feature integration guides also mention the migrations from different features versions

Valerii Trots

Feature integration guide isn't feature migration guide, or is it?

Jeremy Fourna

it is both lol see with @UP5GJTY58 about it

UPWG9AYH2

Thanks a lot for your answers! 🙂

UK7KBE2JW

we currently try to find a way for a project start phase with a (mostly) limited feature set. The easiest way ist probably not to use the feature branches. We also skip them and use the needed packages directly in our project. Thats why I asked some weeks ago for a minimal setup

UPWG9AYH2

I think the feature packages are a good way since this is what you finally want to deliver to your customers, instead of single modules …
I mean in the end you don’t know what packages are required to represent a complete feature.
@UK7KBE2JW from where do you know which feature requires which module?

UK7KBE2JW

Check it manually or with documentation 🙂. We start with https://github.com/spryker-shop/suite/blob/master/composer.json and extract what we need. For example https://github.com/spryker-feature/cms/blob/master/composer.json you really need all of this packages in this feature? For us, we use contentul for cms stuff but need some stuff from spryker cms package since redirect needs it.

UPWG9AYH2

So for me, all modules that are listed in a feature meta package should be required to get this feature to work. Omitting or cherry picking modules would in fact break that rule. All other modules that are not necessarily needed should be in the suggest section of that feature. Using it in that way you don’t have to struggle with changing dependencies within a feature, for example if a module was added/removed in future. At least this is my understanding, otherwise feature packages would not add much value