#Ground rules

#Development principles

1. Avoid including runtime dependencies as much as possible.
2. Write integration tests with this advice.
3. Reuse existing helper functions and helper classes to lower the build size.
4. Use existing linting and code styles, based on configuration.
5. Follow the existing structures for documentation, naming, and structure.

#Environment and defaults

Many defaults are provided by the linting and Prettier configurations. However, to keep the codebase consistent and clean, we have established a set of rules:

• Use git message decoration to ensure correct publish versioning.
• Use naming conventions when possible.
• Use best practices for CSS style structures.
• Use nested CSS class selectors with SCSS and BEM (Block Element Modifier).
• Use React Hooks over React class components when possible.
• Use TypeScript.

#Automated review rules

Define automated Eufemia guidance once and expose it through the tools that can reliably detect or explain it:

1. Give every review rule a stable ID, classification, default severity, documentation, supported tools, and explicit autofix status.
2. Add lint detection only when source-level analysis can identify the issue without rejecting supported APIs or context-dependent alternatives.
3. Add an automatic fix only when the transformation is deterministic and preserves behavior. Otherwise, report the finding with guidance.
4. Expose published rule metadata through the Eufemia MCP server so code-review tools use the same classification and documentation as the lint plugins.
5. Keep version-specific codemods and historical migration guidance in the relevant release documentation.

Requirements, deprecations, recommendations, and context-dependent alternatives must remain distinguishable. Team-specific architecture is not an Eufemia compliance rule, and automated review does not replace integration, accessibility, or visual testing.

Use a dedicated structured MCP catalogue when clients need to enumerate an expanding set of stable rule IDs and share their classification across tools. Keep small static capability matrices in package APIs and documentation unless a broader metadata interface is introduced. This avoids adding one MCP tool for every isolated fact while preserving machine-readable review contracts.

#Where a component change belongs

Choose ownership based on the responsibility of the change, not only on where a similar component already exists:

• Add generic UI components, accessibility behavior, design tokens, themes and reusable form primitives to Eufemia.
• Add business-domain or product-platform compositions to the shared library for that product area.
• Keep application-specific workflows and presentation in the application.

When Eufemia is missing functionality that would be useful across products, evaluate an Eufemia contribution before introducing a permanent wrapper or parallel implementation. An existing component in another shared library does not automatically take precedence over Eufemia. Consider its ownership, behavior and intended reuse.

Use a local abstraction when the requirement is genuinely product-specific or cannot yet be supported by Eufemia. Keep the boundary explicit so generally useful behavior can move into Eufemia later without carrying business concerns with it.

#DNB Code of conduct

This code of conduct outlines our expectations for participants within the DNB community, as well as steps to reporting unacceptable behavior. We are committed to providing a welcoming and inspiring community for all and expect our code of conduct to be honored. Anyone who violates this code of conduct may be banned from the community.

Our open source community strives to:

• Be friendly and patient.
• Be welcoming: We strive to be a community that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, color, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability.
• Be considerate: Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account when making decisions. Remember that we're a worldwide community, so you might not be communicating in someone else's primary language.
• Be respectful: Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one.
• Be careful in the words that you choose: we are a community of professionals, and we conduct ourselves professionally. Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren't acceptable. This includes, but is not limited to:
  • Violent threats or language directed against another person.
  • Discriminatory jokes and language.
  • Posting sexually explicit or violent material.
  • Posting (or threatening to post) other people's personally identifying information ("doxing").
  • Personal insults, especially those using racist or sexist terms.
  • Unwelcome sexual attention.
  • Advocating for, or encouraging, any of the above behavior.
  • Repeated harassment of others. In general, if someone asks you to stop, then stop.
• When we disagree, try to understand why: Disagreements, both social and technical, happen all the time. It is important that we resolve disagreements and differing views constructively. Remember that we’re different. The strength of our community comes from its diversity, people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to err and blaming each other doesn’t get us anywhere. Instead, focus on helping to resolve issues and learning from mistakes.

This code is not exhaustive or complete. It serves to distill our common understanding of a collaborative, shared environment, and goals. We expect it to be followed in spirit as much as in the letter.

#Diversity Statement

We encourage everyone to participate and are committed to building a community for all. Although we may not be able to satisfy everyone, we all agree that everyone is equal. Whenever a participant has made a mistake, we expect them to take responsibility for it. If someone has been harmed or offended, it is our responsibility to listen carefully and respectfully and do our best to right the wrong.

Although this list cannot be exhaustive, we explicitly honor diversity in age, gender, gender identity or expression, culture, ethnicity, language, national origin, political beliefs, profession, race, religion, sexual orientation, socioeconomic status, and technical ability. We will not tolerate discrimination based on any of the protected characteristics above, including participants with disabilities.

#Reporting Unacceptable Behavior Guidelines

If you experience or witness unacceptable behavior or have any other concerns—please report it by contacting us. All reports will be handled with discretion. In your report please include:

• Your contact information.
• Names (real, nicknames, or pseudonyms) of any individuals involved. If there are additional witnesses, please include them as well. Your account of what occurred, and if you believe the incident is ongoing. If there is a publicly available record (e.g. a mailing list archive or a public IRC logger), please include a link.
• Any additional information that may be helpful.

After filing a report, a representative will contact you personally. If the person who is harassing you is part of the response team, they will recuse themselves from handling your incident. A representative will then review the incident, follow up with any additional questions, and make a decision as to how to respond. We will respect confidentiality requests for the purpose of protecting victims of abuse.

Anyone asked to stop unacceptable behavior is expected to comply immediately. If an individual engages in unacceptable behavior, the representative may take any action they deem appropriate, up to and including a permanent ban from our community without warning.

Starter

Edit on GitHub