Use resolve.modules instead of explicit aliases when adding NPM packages

[tobiasberge]

• Currently our webpack docs tell to use explicit aliases when adding an NPM package, see: https://developer.shopware.com/docs/guides/plugins/plugins/plugin-fundamentals/using-npm-dependencies
• While this works fine in general, it requirers an alias for each new NPM package.
• It can also cause problems when the NPM package points to native ES modules directly which will be also bundled by our webpack build (instead of pointing to a pre-bundled JS). Because sub-modules import 'package-name/sub-stuff' within the node_modules code would also need an extra alias.
  • This can lead to strange behavior (some packages work, some do not)

I propose to use resolve.modules instead for apps/plugins and including the entire node_modules folder:

• https://webpack.js.org/configuration/resolve/#resolvemodules
• https://v4.webpack.js.org/configuration/resolve/#resolvemodules

module.exports = (params) => {
    return {
        resolve: {
+            modules: [
+                `${params.basePath}/Resources/app/storefront/node_modules`,
+            ],
-            alias: {
-                'algoliasearch/lite': resolve(
-                    join(__dirname, '..', 'node_modules', 'algoliasearch/lite')
-                ),
-                'instantsearch.js': resolve(
-                    join(__dirname, '..', 'node_modules', 'instantsearch.js')
-                ),
-                'algoliasearch-helper': resolve(
-                    join(__dirname, '..', 'node_modules', 'algoliasearch-helper')
-                ),
-                'hogan.js': resolve(
-                    join(__dirname, '..', 'node_modules', 'hogan.js')
-                ),
-                '@algolia/autocomplete-core': resolve(
-                    join(__dirname, '..', 'node_modules', '@algolia/autocomplete-core')
-                ),
-                // etc...
-            }
        }
    };
}

[tobiasberge]

• Check what happens when two extensions require the same package with different versions.

I added blocked label until further testing is done.

[Isengo1989]

@tobiasberge short follow-up - was the mentioned test successful, or is it outstanding?

[tobiasberge]

@Isengo1989 Hey, sorry for the long delay. In 6.5.x this had side effects when to apps used the same npm package with a different version. I'll have to re-test it for 6.6 because we migrated to webpack multi compiler. With 6.6 this should be fine / more safe because every App/Plugin gets a separate build process under the hood.

Feel free to close this PR in the meantime if you want to keep the PRs clean. I can re-open or create a new one.

[Isengo1989]

@Isengo1989 Hey, sorry for the long delay. In 6.5.x this had side effects when to apps used the same npm package with a different version. I'll have to re-test it for 6.6 because we migrated to webpack multi compiler. With 6.6 this should be fine / more safe because every App/Plugin gets a separate build process under the hood.

Feel free to close this PR in the meantime if you want to keep the PRs clean. I can re-open or create a new one.

No worries, as discussed we leave the PR in draft till everything is figured out for v6.6

[Isengo1989]

@tobiasberge as discussed in Slack I added the main.js info, updated some grammar and added the build commands. We will merge it in next-6.6 soon (changed the target branch).

@bojanrajh rdy to merge 👋