@hug/hospitality 0.0.4-alpha.14 → 0.0.4-alpha.16

package/CODE_OF_CONDUCT.md

@@ -1,135 +0,0 @@
-# Contributor Covenant Code of Conduct
-
-## Our Pledge
-
-We as members, contributors, and leaders pledge to make participation in our
-community a harassment-free experience for everyone, regardless of age, body
-size, visible or invisible disability, ethnicity, sex characteristics, gender
-identity and expression, level of experience, education, socio-economic status,
-nationality, personal appearance, race, caste, color, religion, or sexual identity
-and orientation.
-
-We pledge to act and interact in ways that contribute to an open, welcoming,
-diverse, inclusive, and healthy community.
-
-## Our Standards
-
-Examples of behavior that contributes to a positive environment for our
-community include:
-
-* Demonstrating empathy and kindness toward other people
-* Being respectful of differing opinions, viewpoints, and experiences
-* Giving and gracefully accepting constructive feedback
-* Accepting responsibility and apologizing to those affected by our mistakes,
-  and learning from the experience
-* Focusing on what is best not just for us as individuals, but for the
-  overall community
-
-Examples of unacceptable behavior include:
-
-* The use of sexualized language or imagery, and sexual attention or
-  advances of any kind
-* Trolling, insulting or derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or email
-  address, without their explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
-  professional setting
-
-## Enforcement Responsibilities
-
-Community leaders are responsible for clarifying and enforcing our standards of
-acceptable behavior and will take appropriate and fair corrective action in
-response to any behavior that they deem inappropriate, threatening, offensive,
-or harmful.
-
-Community leaders have the right and responsibility to remove, edit, or reject
-comments, commits, code, wiki edits, issues, and other contributions that are
-not aligned to this Code of Conduct, and will communicate reasons for moderation
-decisions when appropriate.
-
-## Scope
-
-This Code of Conduct applies within all community spaces, and also applies when
-an individual is officially representing the community in public spaces.
-Examples of representing our community include using an official e-mail address,
-posting via an official social media account, or acting as an appointed
-representative at an online or offline event.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by opening an issue or contacting one or more of the project maintainers.
-
-All complaints will be reviewed and investigated promptly and fairly.
-
-All community leaders are obligated to respect the privacy and security of the
-reporter of any incident.
-
-## Enforcement Guidelines
-
-Community leaders will follow these Community Impact Guidelines in determining
-the consequences for any action they deem in violation of this Code of Conduct:
-
-### 1. Correction
-
-**Community Impact**: Use of inappropriate language or other behavior deemed
-unprofessional or unwelcome in the community.
-
-**Consequence**: A private, written warning from community leaders, providing
-clarity around the nature of the violation and an explanation of why the
-behavior was inappropriate. A public apology may be requested.
-
-### 2. Warning
-
-**Community Impact**: A violation through a single incident or series
-of actions.
-
-**Consequence**: A warning with consequences for continued behavior. No
-interaction with the people involved, including unsolicited interaction with
-those enforcing the Code of Conduct, for a specified period of time. This
-includes avoiding interactions in community spaces as well as external channels
-like social media. Violating these terms may lead to a temporary or
-permanent ban.
-
-### 3. Temporary Ban
-
-**Community Impact**: A serious violation of community standards, including
-sustained inappropriate behavior.
-
-**Consequence**: A temporary ban from any sort of interaction or public
-communication with the community for a specified period of time. No public or
-private interaction with the people involved, including unsolicited interaction
-with those enforcing the Code of Conduct, is allowed during this period.
-Violating these terms may lead to a permanent ban.
-
-### 4. Permanent Ban
-
-**Community Impact**: Demonstrating a pattern of violation of community
-standards, including sustained inappropriate behavior,  harassment of an
-individual, or aggression toward or disparagement of classes of individuals.
-
-**Consequence**: A permanent ban from any sort of public interaction within
-the community.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage],
-version 2.0, available at
-[https://www.contributor-covenant.org/version/2/0/code_of_conduct.html][v2.0].
-
-Community Impact Guidelines were inspired by
-[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
-
-For answers to common questions about this code of conduct, see the FAQ at
-[https://www.contributor-covenant.org/faq][FAQ]. Translations are available
-at [https://www.contributor-covenant.org/translations][translations].
-
-
-
-
-[homepage]: https://www.contributor-covenant.org
-[v2.0]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html
-[Mozilla CoC]: https://github.com/mozilla/diversity
-[FAQ]: https://www.contributor-covenant.org/faq
-[translations]: https://www.contributor-covenant.org/translations

package/CONTRIBUTING.md

@@ -1,289 +0,0 @@
-# Contributing
-
-We would love for you to contribute to this project and help make it even better than it is today!
-As a contributor, here are the guidelines we would like you to follow:
-
--   [Code of Conduct](#coc)
--   [Question or Problem?](#question)
--   [Issues and Bugs](#issue)
--   [Feature Requests](#feature)
--   [Submission Guidelines](#submit)
--   [Coding Rules](#rules)
--   [Commit Message Guidelines](#commit)
-
-## <a name="coc"></a> Code of Conduct
-
-Please read and follow our [Code of Conduct][coc], and help us keep this project open and inclusive.
-
-## <a name="question"></a> Got a Question or Problem ?
-
-Please open an issue and add the `question` label to it.
-
-## <a name="issue"></a> Found a Bug ?
-
-If you find a bug in the source code, you can help us by [submitting an issue](#submit-issue) to our [GitHub Repository][github].
-
-Even better, you can [submit a Pull Request](#submit-pr) with a fix.
-
-## <a name="feature"></a> Missing a Feature ?
-
-You can _request_ a new feature by [submitting an issue](#submit-issue) to our [GitHub Repository][github].
-
-If you would like to _implement_ a new feature, please consider the size of the change in order to determine the right steps to proceed:
-
--   For a **Major Feature**, first open an issue and outline your proposal so that it can be discussed.
-    This process allows us to better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.
-
-    **Note**: Adding a new topic to the documentation, or significantly re-writing a topic, counts as a major feature.
-
--   **Small Features** can be crafted and directly [submitted as a Pull Request](#submit-pr).
-
-## <a name="submit"></a> Submission Guidelines
-
-### <a name="submit-issue"></a> Submitting an Issue
-
-Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you of workarounds readily available.
-
-We want to fix all the issues as soon as possible, but before fixing a bug we need to reproduce and confirm it.
-In order to reproduce bugs, we require that you provide a minimal reproduction.
-Having a minimal reproducible scenario gives us a wealth of important information without going back and forth to you with additional questions.
-
-A minimal reproduction allows us to quickly confirm a bug (or point out a coding problem) as well as confirm that we are fixing the right problem.
-
-We require a minimal reproduction to save maintainers' time and ultimately be able to fix more bugs.
-Often, developers find coding problems themselves while preparing a minimal reproduction.
-We understand that sometimes it might be hard to extract essential bits of code from a larger codebase but we really need to isolate the problem before we can fix it.
-
-Unfortunately, we are not able to investigate / fix bugs without a minimal reproduction, so if we don't hear back from you, we are going to close an issue that doesn't have enough info to be reproduced.
-
-You can file new issues by selecting and filling out the issue template from our [new issue templates][issue-templates].
-
-### <a name="submit-pr"></a> Submitting a Pull Request (PR)
-
-Before you submit your Pull Request (PR) consider the following guidelines:
-
-1. Search [GitHub][github-pr] for an open or closed PR that relates to your submission.
-   You don't want to duplicate existing efforts.
-
-2. Be sure that an issue describes the problem you're fixing, or documents the design for the feature you'd like to add.
-   Discussing the design upfront helps to ensure that we're ready to accept your work.
-
-3. Fork this repository.
-
-4. Make your changes in a new git branch:
-
-    ```sh
-    git checkout -b my-fix-branch master
-    ```
-
-5. Create your patch, **including appropriate test cases**.
-
-6. Follow our [Coding Rules](#rules).
-
-7. Run a full test suite and ensure that all tests pass.
-
-8. Commit your changes using a descriptive commit message that follows our [commit message conventions](#commit).
-   Adherence to these conventions is necessary because release notes are automatically generated from these messages.
-
-    ```sh
-    git commit --all
-    ```
-
-    Note: the optional commit `-a` command line option will automatically "add" and "rm" edited files.
-
-9. Push your branch to GitHub:
-
-    ```sh
-    git push origin my-fix-branch
-    ```
-
-10. In GitHub, send a pull request to `develop` branch.
-
-### Reviewing a Pull Request
-
-Pull requests may not be accepted from community members who haven't been good citizens of the community.
-
-Such behavior includes not following the [code of conduct](#coc) and applies within or outside of this repository.
-
-#### Addressing review feedback
-
-If we ask for changes via code reviews then:
-
-1. Make the required updates to the code.
-
-2. Re-run the test suites to ensure tests are still passing.
-
-3. Create a fixup commit and push to your GitHub repository (this will update your Pull Request):
-
-    ```sh
-    git commit --all --fixup HEAD
-    git push
-    ```
-
-That's it! Thank you for your contribution!
-
-#### Updating the commit message
-
-A reviewer might often suggest changes to a commit message (for example, to add more context for a change or adhere to our [commit message guidelines](#commit)).
-
-In order to update the commit message of the last commit on your branch:
-
-1. Check out your branch:
-
-    ```sh
-    git checkout my-fix-branch
-    ```
-
-2. Amend the last commit and modify the commit message:
-
-    ```sh
-    git commit --amend
-    ```
-
-3. Push to your GitHub repository:
-
-    ```sh
-    git push --force-with-lease
-    ```
-
-> NOTE:<br />
-> If you need to update the commit message of an earlier commit, you can use `git rebase` in interactive mode.
-> See the [git docs](https://git-scm.com/docs/git-rebase#_interactive_mode) for more details.
-
-#### After your pull request is merged
-
-After your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository:
-
--   Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
-
-    ```sh
-    git push origin --delete my-fix-branch
-    ```
-
--   Check out the master branch:
-
-    ```sh
-    git checkout master -f
-    ```
-
--   Delete the local branch:
-
-    ```sh
-    git branch -D my-fix-branch
-    ```
-
--   Update your master with the latest upstream version:
-
-    ```sh
-    git pull --ff upstream master
-    ```
-
-## <a name="rules"></a> Coding Rules
-
-To ensure consistency throughout the source code, keep these rules in mind as you are working:
-
--   All features or bug fixes **must be tested** by one or more specs (unit-tests)
--   All public API methods **must be documented**
--   We follow [Google's JavaScript Style Guide][js-style-guide], but wrap all code at **100 characters**
-
-## <a name="commit"></a> Commit Message Format
-
-_This specification is inspired by and supersedes the [Conventional Commits message format][commit-message-format]._
-
-We have very precise rules over how our Git commit messages must be formatted.
-
-This format leads to **easier to read commit history**.
-
-Each commit message consists of a **header**, a **body**, and a **footer**.
-
-```
-<header>
-<BLANK LINE>
-<body>
-<BLANK LINE>
-<footer>
-```
-
-The `header` is mandatory and must conform to the [Commit Message Header](#commit-header) format.
-
-The `body` is mandatory for all commits except for those of type "docs". When the body is present it must be at least 20 characters long and must conform to the [Commit Message Body](#commit-body) format.
-
-The `footer` is optional. The [Commit Message Footer](#commit-footer) format describes what the footer is used for and the structure it must have.
-
-Any line of the commit message cannot be longer than 100 characters.
-
-#### <a name="commit-header"></a> Commit Message Header
-
-```
-<type>(<scope>): <short summary>
-  │       │             │
-  │       │             └─⫸ Summary in present tense. Not capitalized. No period at the end.
-  │       │
-  │       └─⫸ Commit Scope (optional): provide additional contextual information
-  │
-  └─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test
-```
-
-##### Type
-
-Must be one of the following:
-
--   **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
--   **ci**: Changes to CI configuration files and scripts (example scopes: Circle, BrowserStack, SauceLabs)
--   **docs**: Documentation only changes
--   **feat**: A new feature
--   **fix**: A bug fix
--   **perf**: A code change that improves performance
--   **refactor**: A code change that neither fixes a bug nor adds a feature
--   **test**: Adding missing tests or correcting existing tests
-
-##### Scope
-
-Scope can be anything specifying place of the commit change.
-
-##### Summary
-
-Use the summary field to provide a succinct description of the change:
-
--   use the imperative, present tense: "change" not "changed" nor "changes"
--   don't capitalize the first letter
--   no dot (.) at the end
-
-#### <a name="commit-body"></a> Commit Message Body
-
-Just as in the summary, use the imperative, present tense: "fix" not "fixed" nor "fixes".
-
-Explain the motivation for the change in the commit message body. This commit message should explain _why_ you are making the change.
-
-You can include a comparison of the previous behavior with the new behavior in order to illustrate the impact of the change.
-
-#### <a name="commit-footer"></a> Commit Message Footer
-
-The footer can contain information about breaking changes and is also the place to reference GitHub issues, Jira tickets, and other PRs that this commit closes or is related to.
-
-```
-BREAKING CHANGE: <breaking change summary>
-<BLANK LINE>
-<breaking change description + migration instructions>
-<BLANK LINE>
-<BLANK LINE>
-Fixes #<issue number>
-```
-
-Breaking Change section should start with the phrase `BREAKING CHANGE: ` followed by a summary of the breaking change, a blank line, and a detailed description of the breaking change that also includes migration instructions.
-
-### Revert commits
-
-If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit.
-
-The content of the commit message body should contain:
-
--   information about the SHA of the commit being reverted in the following format: `This reverts commit <SHA>`
--   a clear description of the reason for reverting the commit message
-
-[coc]: https://github.com/dsi-hug/hospitality/blob/main/CODE_OF_CONDUCT.md
-[github]: https://github.com/dsi-hug/hospitality
-[issue-templates]: https://github.com/dsi-hug/hospitality/issues/new/choose
-[github-pr]: https://github.com/dsi-hug/hospitality/pulls
-[js-style-guide]: https://google.github.io/styleguide/jsguide.html
-[commit-message-format]: https://www.conventionalcommits.org/en/v1.0.0

package/DEVELOPER.md

@@ -1,37 +0,0 @@
-# Development
-
-This document describes how you can test, build and publish the library and its documentation.
-
-## Prerequisite
-
-Before you can build and test this library you must install and configure the following products on your development machine:
-
--   [Git][git]
--   [Node.js][nodejs]
-
-You will then need to install the required dependencies:
-
-```sh
-cd <library-path>
-npm install
-```
-
-## Linting/verifying source code
-
-Check that the code is properly formatted and adheres to coding style.
-
-```sh
-npm run lint
-```
-
-## Publishing the library to NPM repository
-
-This project comes with automatic continuous delivery (CD) using _GitHub Actions_.
-
-1. Bump the library version in `package.json`
-2. Push the changes
-3. Create a new: [GitHub release](https://github.com/dsi-hug/hospitality/releases/new)
-4. Watch the results in: [Actions](https://github.com/dsi-hug/hospitality/actions)
-
-[git]: https://git-scm.com/
-[nodejs]: https://nodejs.org/

package/material/core/directives/components-styling.directive.ts

@@ -1,20 +0,0 @@
-/* eslint-disable @typescript-eslint/naming-convention */
-import { Directive, input } from '@angular/core';
-
-export type HySizeType = 'x-small' | 'small' | 'medium' | 'large' | 'x-large';
-
-@Directive({
-    selector: `
-        [hy-size],
-        [hy-appearance]
-    `,
-    standalone: true,
-    host: {
-        '[attr.hy-size]': 'hySize()',
-        '[attr.hy-appearance]': 'hyAppearance()'
-    }
-})
-export class ComponentsStylingDirective {
-    public hySize = input<HySizeType | null>(null, { alias: 'hy-size' });
-    public hyAppearance = input<string | null>(null, { alias: 'hy-appearance' });
-}

package/material/core/ng-package.json

@@ -1,7 +0,0 @@
-{
-    "$schema": "../../node_modules/ng-packagr/ng-package.schema.json",
-    "lib": {
-        "flatModuleFile": "core",
-        "entryFile": "./index.ts"
-    }
-}

package/material/form-field/ng-package.json

@@ -1,7 +0,0 @@
-{
-    "$schema": "../../node_modules/ng-packagr/ng-package.schema.json",
-    "lib": {
-        "flatModuleFile": "form-field",
-        "entryFile": "./index.ts"
-    }
-}

package/ng-package.json

@@ -1,10 +0,0 @@
-{
-    "$schema": "./node_modules/ng-packagr/ng-package.schema.json",
-    "assets": [
-        "./material/**/*.scss",
-        "./tokens/tokens.css"
-    ],
-    "lib": {
-        "entryFile": "./index.ts"
-    }
-}

package/tokens/ng-package.json

@@ -1,7 +0,0 @@
-{
-    "$schema": "../node_modules/ng-packagr/ng-package.schema.json",
-    "lib": {
-        "flatModuleFile": "tokens",
-        "entryFile": "./index.ts"
-    }
-}