First off, thanks for taking the time to contribute! ❤️
All types of contributions are encouraged and valued. See the Table of Contents for different ways to help and details about how this project handles them. Please make sure to read the relevant section before making your contribution. It will make it a lot easier for us maintainers and smooth out the experience for all involved. The community looks forward to your contributions. 🎉
And if you like the project, but just don't have time to contribute, that's fine. There are other easy ways to support the project and show your appreciation, which we would also be very happy about:
- Star the project
- Tweet about it
- Refer this project in your project's readme
- Mention the project at local meetups and tell your friends/colleagues
- Code of Conduct
- I Want To Contribute
- Issue workflow
- Reporting Bugs
- Suggesting Enhancements
- Your First Code Contribution
- Improving The Documentation
- Commit Messages
This project and everyone participating in it is governed by the Siemens Industrial Experience Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected] or [email protected].
When contributing to this project, you must agree that you have authored 100% of the content, that you have the necessary rights to the content and that the content you contribute may be provided under the project license.
You must never report security related issues, vulnerabilities or bugs including sensitive information to the issue tracker, or elsewhere in public. Instead sensitive bugs must be sent by email to [email protected] or [email protected].
We use GitHub issues to track bugs and errors. If you run into an issue with the project:
- Open an Issue. (Since we can't be sure at this point whether it is a bug or not, we ask you not to talk about a bug yet and not to label the issue.)
- Explain the behavior you would expect and the actual behavior.
- Please provide as much context as possible and describe the reproduction steps that someone else can follow to recreate the issue on their own. This usually includes your code. For good bug reports you should isolate the problem and create a reduced test case.
- Provide the information you collected in the previous section.
Once it's filed:
- The project team will label the issue accordingly.
Workflow: Issue created
- A team member will try to reproduce the issue with your provided steps. If there are no reproduction steps or no obvious way to reproduce the issue, the team will ask you for those steps and mark the issue as
needs-repro
. Bugs with theneeds-repro
label will not be addressed until the steps to reproduce it have been provided. Ideally you can provide a link to a running example (e.g. StackBlitz). - If the team is able to reproduce the issue, it will be marked
type: bug
andWorkflow: Approved
, as well as possibly other labels (such astype: enhancement
) - If work on the issue has begun the workflow label will be changed to
Workflow: In progress
- Read the documentation carefully and find out if the functionality is already covered, maybe by an individual configuration.
- Perform a search to see if the enhancement has already been suggested. If it has, add a comment to the existing issue instead of opening a new one.
- Find out whether your idea fits with the scope and aims of the project. It's up to you to make a strong case to convince the project's developers of the merits of this feature. Keep in mind that we want features that will be useful to the majority of our users and not just a small subset. If you're just targeting a minority of users, consider writing an add-on/plugin library.
Enhancement suggestions are tracked as GitHub issues.
- Use a clear and descriptive title for the issue to identify the suggestion.
- Provide a step-by-step description of the suggested enhancement in as many details as possible.
- Describe the current behavior and explain which behavior you expected to see instead and why. At this point you can also tell which alternatives do not work for you.
- You may want to include screenshots and animated GIFs which help you demonstrate the steps or point out the part which the suggestion is related to. You can use this tool to record GIFs on macOS and Windows, and this tool or this tool on Linux.
- Explain why this enhancement would be useful to most Siemens iX users. You may also want to point out the other projects that solved it better and which could serve as inspiration.
- Download the installer for the LTS version of Node.js. This is the best way to also install pnpm.
- Fork this repository.
- Clone your fork.
- Create a new branch from main for your change.
- Run
pnpm install
to install dependencies. - Navigate into the directory of the package you wish to modify (core, angular, etc.).
- Follow the steps for the specific package below.
- Locate the component(s) to modify inside
/packages/core/src/components/
. - Take a look at the Stencil Documentation and other components to understand the implementation of these components.
- Make your changes to the component. If the change is overly complex or out of the ordinary, add comments so we can understand the changes.
- Preview your changes locally.
- Modify the documentation if needed.
- Run lint on the directory and make sure there are no errors.
- Build the project.
- After the build is finished, commit the changes. Please follow the commit message format for every commit.
Stencil's primary goal is to remove the need for components to be written using a specific framework's API. It accomplishes this by using standardized web platform APIs that work across all modern browsers. Using the low-level component model that is provided by the browser (which all frameworks are built on) allows Stencil components to work inside a framework or without one.
The experience of integrating web components directly into existing applications can be tricky at times, as frameworks have varying support for vanilla web components. In order to accommodate the various issues the Stencil team has created Framework Wrappers to make the process simpler.
Read more about the Stencil Output Targets here
Please be aware you can not modify angular, react and vue components directly. Some files are marked with a jsdocs
/* auto-generated react proxies */
. These files will be overwritten by each build!
- Locate the files inside the relevant root directory:
- Angular:
/packages/angular
- React:
/packages/react
- Vue:
/packages/vue
- Make your changes to the files. If the change is overly complex or out of the ordinary, add comments so we can understand the changes.
- Run lint on the directory and make sure there are no errors.
- Build the project.
- After the build is finished, commit the changes. Please follow the commit message format for every commit.
- Submit a Pull Request of your changes.
- Run
pnpm start --filter @siemens/ix
from within theroot
directory. - A browser should open at
http://localhost:3333/
. - Edit and safe
/packages/core/src/components/my-component/my-component.tsx
to review your changes.
- Run
pnpm start --filter @siemens/angular-test-app
from within theroot
directory. - A browser should open at
http://localhost:4200/previews/button
. - Edit or add an example in
packages/angular-test-app/src/preview-examples
. - Navigate to
http://localhost:4200/previews/{your-example-file-name}
to review your changes.
- Run
pnpm start --filter @siemens/react-test-app
from within theroot
directory. - A browser should open at
http://localhost:5173/previews/buttons
. - Edit or add an example in
packages/react-test-app/src/preview-examples/buttons
. - Navigate to
http://localhost:5173/previews/{your-example-file-name}
to review your changes.
- Run
pnpm start --filter @siemens/angular-test-app
from within theroot
directory. - A browser should open at
http://localhost:5173/previews/buttons
. - Edit or add an example in
packages/vue-test-app/src/preview-examples/buttons
. - Navigate to
http://localhost:5173/previews/{your-example-file-name}
to review your changes.
- Run
pnpm start --filter @siemens/html-test-app
from within theroot
directory. - A browser should open at
http://localhost:5173/preview-examples/buttons.html
. - Edit or add an example in
packages/vue-test-app/src/preview-examples/buttons
. - Navigate to
http://localhost:5173/preview-examples/{your-example-file-name}.html
to test and preview your changes.
- Run
pnpm lint
from within theroot
directory.
- Run
pnpm build
from within theroot
directory. - Make sure you have committed all changes.
pnpm test
Docker cli must be installed on your system
If you execute the visual-regression tests, please be sure to execute the build step before.
-
Build the library
pnpm build --filter \!documentation
-
Start playwright docker container. (Currently v1.30.0-focal but can be a newer version)
docker run -p 8080:8080 -v $(pwd):/work/ -w /work -it mcr.microsoft.com/playwright:v1.30.0-focal /bin/bash
- Start the test suite
-
All tests run
pnpm visual-regression
-
Workspace run
pnpm visual-regression --filter @siemens/ix
-
Check the results in
packages/<workspace>/playwright-report/index.html
-
Adapt and update snapshots with
pnpm --filter @siemens/ix run visual-regression <test name> -u
-
Check the git diff and commit changes 🎉
- Run
pnpm start --filter documentation
from within theroot
directory. - Locate the docs(s) to modify inside
/packages/documentation/docs/
.
- html-test-app
- angular-test-app
- react-test-app
- vue-test-app
These packages contain playground applications to explore and test the respective ix
components.
The preview source code for the documentation is also located inside the x-test-app
's. (src/preview-examples
)
These preview-examples will be translated to markdown files and get copied into ./packages/documentation/docs/auto-generated/previews
.
You need to have access to the internal figma library
To see all image references it is necessary to create a personal access token (https://www.figma.com/developers/api#access-tokens).
Store the token as environment variable "FIGMA_API_TOKEN" or in the .env file inside root.
Serve documentation locally
pnpm start --filter=documentation
<type>(<scope>): <short summary>
│ │ │
│ │ └─⫸ Summary in present tense. Not capitalized. No period at the end.
│ │
│ └─⫸ Commit Scope: animations|bazel|benchpress|common|compiler|compiler-cli|core|
│ elements|forms|http|language-service|localize|platform-browser|
│ platform-browser-dynamic|platform-server|router|service-worker|
│ upgrade|zone.js|packaging|changelog|dev-infra|docs-infra|migrations|
│ ngcc|ve
│
└─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test
The <type>
and <summary>
fields are mandatory, the (<scope>)
field is optional.
If you execute pnpm install
you will get git hooks which verify the git commit message.
Checkout more details here
Must be one of the following:
- build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
- ci: Changes to our 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
- Create a new pull request with the
main
branch as thebase
. You may need to click oncompare across forks
to find your changes. - See the Creating a pull request from a fork GitHub help article for more information.
- Please fill out the provided Pull Request template to the best of your ability and include any issues that are related.
- Create a changeset to help us prepare a release. If you are not sure what to do just skip this step, a maintainer will comment on the pull request.
This guide is based on the contributing-gen. Make your own!