Codey

Appearance

Report a problem:

Problems can be reported via Microsoft Teams in your team channel within the "IT - Codey" team.

Please include the following information:

Report type:
Docs problem report a bug instead →
Path:
/vnext/contributing/adr/records/005__limit-vite-rollup-externals-to-peer-and-xerius-packages.html
Message:

DESCRIBE THE PROBLEM BEFORE SUBMITTING TO CODEY

Limit vite rollup externals to peer and Xerius packages ​

Status: Rejected (See Set all peer- and dependencies as external )

Decision Date: 15/12/2022

Scope: codey-components, codey-composables

Context ​

When migrating to Vite I noticed that allot of externals are defined. We took a deeper look into the purpose of this field an can conclude the following:

Packages that are defined as external will not have their imports included in the bundled output. They will be called upon at runtime.

In our SPA app context this means that external packages will be used based on the installed dependencies on the consumers end when bundling your app.

The drawback of this approach is that the applications using our library potentially use different versions that we ourself tested and developed against. This can lead to unforeseen situation an hard to recreate bugs.

Decision ​

We decided to automatically include peer dependencies as externals and all @xerius packages. Other external packages used are limited to 1 - 3 modules of the library making code optimization not needed.

Note: if a new dependency is widely used in different parts of the library it is advised to consider it as external. As this is the best way to let consumer optimize their build output.

Peer dependencies ​

Peer dependencies are meant to be installed by the consumer and therefor intentionally left out of the bundle. This allows for updates of main frameworks without the need of updating codey. These are also typically intensively used within the library. So not putting them as external would result in multiple instances of the same code being bundled.

@Xerius packages ​

We have full control over @xerius packages and therefor can rely on upholding semver and backward compatibility. Like peer dependencies, these can also be used multiple times, making them external beneficial for code optimization.

Consequences ​

All dependencies not defined as external within the library will be bundled and shipped. This creates modules containing all required code to run without the need of additional bundling at the consumers end.

This will slightly increase the bundle time of our libraries for including non external dependencies.

Alternatives ​

Define all dependencies as external and lock in the versions of the dependencies.