The context for this is that I'm working on a NextJS project that depends on persistent state management. Next handles navigation between pages using their own Link component. I wanted to make a fork of the LinkBox component, modified slightly to use Next Link instead of our built in link utility. When I copied over the source for the component, and updated all of the imports to pull from '@UA-Stratcom/minerva', typescript had several issues.

## Description

When installing minerva as a package, it would be helpful to be able to import type declarations for use in custom components or to extend minerva components, respecting the component interfaces. To do this, one would expect to import the type like below:

```tsx
import type { icon } from "@UA-Stratcom/minerva";
```

However this doesn't work, as the types themselves are not exported in the compiled types.d.ts file that is distributed with the package.

## How to Reproduce

Steps to reproduce the behavior:

1. Create a NextJS app (you can use the starter template)
2. Try creating a new component, but using one of Minerva's types in the props
3. Import the type from Minerva using the syntax above
4. See errors

## Expected behavior

We should have a way for users to import our types for use in their own projects

## Screenshots

If applicable, add screenshots to help explain your problem.

## Additional context

I looked into this for quite a while late last night and I'm pretty sure there's some configuration issue in one of the files: `package.json` `rollup.config.js` or `tsconfig.json`

I tried asking Copilot and while it did provide some interesting advice, I think it doesn't understand the intricacies of how our package is built for distribution, since it passes through several steps.

## Side note

It would be very cool if we could figure out a way to easily use Next Link instead of our link utility without adding Next as a dependency. The only way I can imagine doing this would be either some global level configuration file, which seems extremely complicated, or find someway to replace our Link utility component with a custom one that wraps Next Link so that the props are all the same, just parsed and passed through to Next Link. I'm not sure how to get Minerva to recognize the new component as an override for the existing Link utility. Since our React projects are mostly in NextJS, it may make sense to dedicate some time to solving this issue.

An issue related to developer experience or operations

Minerva 1.6.0

Can't import types from minerva when installed as a package

## Description

UA has held this very sharp edge design for about 5 years now, and recent concepts have floated the idea of rounded corners. We need to look at the design system as a whole and determine how rounded corners fit into the design system, and what it means for existing components and overall visual language.

design

Anything related to architecture / refactors / project structure

core

Evaluate addition of border radius

## Description

WordPress now supports box shadows in the editor, with several enabled by default. @spbrown6 and I talked about this briefly during the last all staff meeting, and decided we would look into how box shadow effects could be applied throughout the design system.

Box shadows don't necessarily have to be the feathered drop shadows that come to mind, they can be solid and bold or even outlined offsets.

We need to determine the following:

- Are box shadows permitted by the design system
- If so, what presets are there to choose from
- How should those presets be used
- Should they be worked into the default design of any components
- If not, what usage guidelines will we have for box shadows

There may be other questions we run into during this exploration, but those are the big ones that need to be addressed. Basically, how do box shadows fit in the design system.

Evaluate addition of box shadows

blocked

enhancement

Development for Timeline component

## Description

A mockup should be produced following the Minerva design system with annotations for developer handoff. All designs will be considered, but a vertical layout will likely be the most straightforward. The timeline should account for arbitrary content length, a date, and an optional image.


Design for Timeline component

## Background

We've had a couple of requests for a timeline block, and even needed a solution for this on UA home. We ended up going with the workaround below, but it would be nice to have a full fledged component to handle this type of content.

## Description

This is a proposal for a new component that would allow users to display content along a timeline.

## Workarounds

Currently, there are probably multiple ways to display this information but the workaround we used on home was to use headings and content very much like a standard page.


A task related to planning / project management

planning

Timeline Component

## Description

This is a list of things we need to double check to make sure we're in line with the new WCAG 2.2 guidelines.

```[tasklist]
- [ ] 2.5.3 For UI components with labels that include text or images of text, the name attribute contains the text that is presented visually
- [x] 2.5.2 For functionality operated using a single pointer, one of the following is true: The down event is not used to trigger any action, the action can be aborted or the action can be undone, the up event reverses any outcome of the down event, or completing the action on the down event is essential
- [ ] 4.1.3 Status messages can be programmatically determined through role or properties such that they can be presented ti the user by assistive technology without receiving focus
- [ ] 1.4.11 Graphics and UI components must meet contrast guidelines
- [x] 1.4.12 When the following is set by the user: Line height at least 1.5, space between paragraphs at least 2em, letter spacing at least 0.12em and word spacing at least 0.16em, no part of the UI becomes unusable
- [ ] 1.4.13 This is a long one that pertains to content revealed on hover or focus
```

## Notes

For 2.5.3, we mostly just need to check any label elements and make sure the name attribute matches the text inside the label

For 2.5.2, we need to look through all of our JS and make sure nothing is triggered on the mouse down event

For 4.1.3, I need to do some more research on what exactly qualifies as a status message, but this will likely only apply to the alert banner on home. Its possible the Callout component could be used as a status message, so we may need to add a prop to that component to indicate if its an alert or not. I'm wary of this however because I fear content editors will abuse this option. If the Callout component gets this new prop, it should be a checkbox in the theme with a warning beneath it explaining what that checkbox is for and discourage it's use.

For 1.4.11, I need to do some research on what the WC3 classifies as a "UI Component". This could potentially be a lot of trouble if things like cards are included, and may require a re-think of how we handle the color system

For 1.4.13, I'm going to verify that applies to dropdowns on the main navigation. If it does, it may mean we have to change how this component functions.

## Important

This issue is not meant to fix any accessibility violations, only identify if a fix needs to be made. **If we discover anything in violation of these new guidelines, we should open a new accessibility issue to track it specifically.**

Use this thread to discuss these guidelines and their impact on our web framework.

Roadmap

Milestones

Minerva 1.6.0