Implicit or explicit third party dependencies

[brandonjpierce]

We know for a fact that we will be utilizing some third party dependencies for large parts of our toolkit capability. An example being Turfjs.

Given that we have @hypergiant/geo would it make sense to simply export all of turfjs from that package? Would we rather expect the consuming application to add turfjs explicitly? If so how do we manage version drift between what is used in say @hypergiant/geo and the consuming application?

Option 1 (implicit):

import { distance } from '@hypergiant/geo';

Option 2 (explicit):

import { distance } from 'turfjs';

[belsrc]

Discussed some in DTC 07-23-2024. It seems like it would make more sense to mark those dependencies as peer. This would allow the consumer to use them as their on discrepancy. Might make a note that these are peer dependencies and they can import them directly from that library.

[brandonjpierce]

Where this becomes slightly complicated:

Say we had a formatter that we wanted to expose called toFlightLevel. This would take in a altitude value, in say meters, and convert it to feet and then convert it to feet flight level (hundreds of feet). Internally we would do something like:

import { Measure, feet, meters } from 'safe-units'

export function toFlightLevel(value: number) {
  const valueInFeet = Measure.of(value, meters).in(feet);

  return `${valueInFeet / 100}`.padStart(2, '0');
}

Meaning that when people use the following in a consuming application:

import { toFlightLevel } from '@accelint/converters';

toFlightLevel(123);

We would have safe-units as a dependency for @accelint/converters but we would still expect folks to have safe-units as a peerDependency for consuming applications which could cause problems.

[belsrc]

No real difference from us using, say lodash. Plenty of other packages use it internally but in order for us to use it, we need to add it. (Technically Node can still find it even though it is not a direct dep, but we will ignore that).

[ArrayKnight]

I want to run a problem scenario past y'all and see how you feel we should take action:

Problem: If an app is using a different version of react-aria-components than what @accelint/design-system is using, components break due to different instances of React context. Example:

import {MenuTrigger} from 'react-aria-components';
import {Button, Menu} from '@accelint/design-system';
 
<MenuTrigger>
  <Button />
  <Menu>{...}</Menu>
</MenuTrigger>

In this scenario, MenuTrigger provides a context, and Menu consumes context. But because they are separate instances (node_modules/react-aria-components vs node_modules/@accelint/design-system/node_module/react-aria-components) the functionality breaks. This nesting currently can happen in C1

There's a couple possible approaches that I've thought of, but I'd like your ideas as well. Here's a couple that I came up with:

• We add a disclaimer on the DS README.md stately this hard requirement and the issues that arise if it's not adhered to
• We re-export everything from react-aria-components, so an app would only ever import components via the design system which guarantees they are the same version

[brandonjpierce]

After discussing during our TSC meeting 11/12/24, it was decided to go with the peer dependency path as a solution to this problem space.