If you want to create a node which should be added to n8n follow these steps:
1. Read the information in the [n8n-node-dev](https://github.com/n8n-io/n8n/tree/master/packages/node-dev) package as it contains a lot of generic information about node development.
1. Create the n8n development setup like described above and start n8n in develoment mode `npm run dev`
1. Create a new folder for the new node. For a service named "Example" the folder would be called: `/packages/nodes-base/nodes/Example`
1. If there is already a similar node simply copy the existing one in the new folder and rename it. If none exists yet, create a boilerplate node with [n8n-node-dev](https://github.com/n8n-io/n8n/tree/master/packages/node-dev) and copy that one in the folder.
1. If the node needs credentials because it has to authenticate with an API or similar create new ones. Existing ones can be found in folder `/packages/nodes-base/credentials`. Also there it is the easiest to simply copy existing similar ones.
1. Add the path to the new node (and optionally credentials) to package.json of `nodes-base`. It already contains a property `n8n` with its own keys `credentials` and `nodes`.
1. Add icon for the node (60x60 PNG)
1. Start n8n. The new node will then be available via the editor UI and can be tested.
When developing n8n must get restarted and the browser reloaded every time parameters of a node change (like new ones added, removed or changed). Only then will the new data be loaded and the node displayed correctly.
If only the code of the node changes (the execute method) than it is not needed as each workflow automatically starts a new process and so will always load the latest code.
If you'd like to submit a new node, please go through the following checklist. This will help us be quicker to review and merge your PR.
- [ ] Make failing requests to the API to ensure that the errors get displayed correctly (like malformed requests or requests with invalid credentials)
- [ ] Ensure that the default values do not change and that the parameters do not get renamed, as it would break the existing workflows of the users
- [ ] Ensure that all the top-level parameters use camelCase
- [ ] Ensure that all the options are ordered alphabetically, unless a different order is needed for a specific reason
- [ ] Ensure that the parameters have the correct type
- [ ] Make sure that the file-name and the Class name are identical (case sensitive). The name under "description" in the node-code should also be identical (except that it starts with a lower-case letter and that it will never have a space)
- [ ] Names of Trigger-Nodes always have to end with "Trigger"
- [ ] Add credentials and nodes to the `package.json` file in alphanumerical order
- [ ] Use tabs in all the files except in the `package.json` file, where 4-spaces have to get used
- [ ] To make it as simple as possible for the users, check other similar nodes to ensure that they all behave similarly
- [ ] Try to add as few parameters as possible on the main level to ensure that the node doesn't appear overwhelming. It should only contain the required parameters. All the other ones should be hidden on lower levels as "Additional Parameters" or "Options"
That we do not have any potential problems later it is sadly necessary to sign a [Contributor License Agreement](CONTRIBUTOR_LICENSE_AGREEMENT.md). That can be done literally with the push of a button.
We used the most simple one that exists. It is from [Indie Open Source](https://indieopensource.com/forms/cla) which uses plain English and is literally just a few lines long.
A bot will automatically comment on the pull request once it got opened asking for the agreement to be signed. Before it did not get signed it is sadly not possible to merge it in.