[TypeScript] Replace ThemeType Absolute Imports with Relative Imports

[michaeljaltamirano]

We use absolute imports for convenience for much of our CONSTANTS usage. As a result, rollup helps us turn something like import { SPACER } from 'src/constants' into something like import SPACER from '../../../constants/spacer/index.js';.

TypeScript compilation does not do this by design:

1. "TypeScript doesn't modify import paths as part of compilation - you should always write the path you want to appear in the emitted JS"
2. "Our general take on this is that you should write the import path that works at runtime"

As a result, consumer apps have no way to understand our ThemeType in declaration files. The below is an example of radiance-ui/lib/utils/injectGlobalStyles/style.d.ts

import 'focus-visible';
import { ThemeType } from 'src/constants/themes/types';
export declare const resetStyles: string;
export declare const brandStyles: (theme: ThemeType) => string;
//# sourceMappingURL=style.d.ts.map

ThemeType ends up casting to any because the path is not resolvable.

This PR updates all of our ThemeType imports (and some others) to pull from src/constants relatively. As a result the tsc output now points to the actual file definition:

import 'focus-visible';
import { ThemeType } from '../../constants';
export declare const resetStyles: string;
export declare const brandStyles: (theme: ThemeType) => string;
//# sourceMappingURL=style.d.ts.map

There were two alternatives considered, both of which seemed sub-optimal since (I believe) our preference should be for things to "work out of the box":

1. We could use path mapping in tsconfig.json to resolve the absolute path in the consumer app, like so:

"paths": {
  "emotion-theming": ["jsx/types/modules/emotion-theming"],
  "@emotion/styled": ["jsx/types/modules/@emotion/styled"],
  "src/constants/themes/types": ["../../node_modules/radiance-ui/lib/constants/themes/types"]
},

However, it seems inadequate to add an additional usage step in every consumer app, rather than address the issue at the source.

2. We could use some open source tools to modify path aliases: ttypescript (not a typo), ts-transform-paths, etc.

However, it seems likely that making our configuration more complex with two additional tools, some of which do not appear to have more recent updates, would likely make it harder for us to stay up-to-date with TypeScript in the future, and cause other unexpected problems.

When considered along-with the recommendation by the TypeScript team to write the code as it will exist at runtime, the most appropriate course for a component library would seem to be to more heavily rely on relative imports. This PR does not yet include documentation/app-configuration to enforce this, but it unblocks our efforts to release a v13. Looking at component library best practices and updating accordingly could be a cooldown task during the holidays.

[michaeljaltamirano]

Rather than have in all our source files:

import { SPACER } from '../../constants';
import { ThemeType } from '../../constants/theme/types';

We can just combine them for convenience:

import { SPACER, ThemeType } from '../../constants';

[daigof]

Looks good, I was trying to figure it out this TS eslint

have you seen that? Do you think we can do something in emotion-themeing file? (not related to this PR (I think))

[michaeljaltamirano]

Looks good, I was trying to figure it out this TS eslint

have you seen that? Do you think we can do something in emotion-themeing file? (not related to this PR (I think))

Let me take a look. I added some stricter rules but I've also added some disables for those rules when they're in test/etc. files that are less important than functional code.

[michaeljaltamirano]

Looks good, I was trying to figure it out this TS eslint

have you seen that? Do you think we can do something in emotion-themeing file? (not related to this PR (I think))

Let me take a look. I added some stricter rules but I've also added some disables for those rules when they're in test/etc. files that are less important than functional code.

@daigof I pulled in this repo with fresh node_modules and didn't see this error (ran yarn run eslint on the file). I'm going to merge it in so I can do a beta release--could you double-check it's not a stale editor/modules issue?