mudhorn/n8n
1
0
Fork 0
mirror of https://github.com/n8n-io/n8n.git synced 2024-11-09 22:24:05 -08:00
Code Issues Actions Packages Projects Releases Wiki Activity

fix: Minor grammar adjustments (no-changelog) (#6489)

Browse source
This commit is contained in:
Sandra Ashipala 2023-06-26 11:05:05 +02:00 committed by GitHub
parent 665710f432
commit f0ab023c33
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 40 additions and 40 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
CONTRIBUTING.md
View file

@ -54,8 +54,8 @@ The most important directories:
## Development setup
If you want to change or extend n8n you have to make sure that all needed
dependencies are installed and the packages get linked correctly. Here a short guide on how that can be done:
If you want to change or extend n8n you have to make sure that all the needed
dependencies are installed and the packages get linked correctly. Here's a short guide on how that can be done:
### Requirements
@ -69,7 +69,7 @@ dependencies are installed and the packages get linked correctly. Here a short g
##### pnpm workspaces
n8n is split up in different modules which are all in a single mono repository.
n8n is split up into different modules which are all in a single mono repository.
To facilitate the module management, [pnpm workspaces](https://pnpm.io/workspaces) are used.
This automatically sets up file-links between modules which depend on each other.
@ -113,24 +113,24 @@ No additional packages required.
> **IMPORTANT**: All the steps below have to get executed at least once to get the development setup up and running!
Now that everything n8n requires to run is installed the actual n8n code can be
Now that everything n8n requires to run is installed, the actual n8n code can be
checked out and set up:
1. [Fork](https://guides.github.com/activities/forking/#fork) the n8n repository
1. [Fork](https://guides.github.com/activities/forking/#fork) the n8n repository.
2. Clone your forked repository
2. Clone your forked repository:
```
git clone https://github.com/<your_github_username>/n8n.git
```
3. Go into repository folder
3. Go into repository folder:
```
cd n8n
```
4. Add the original n8n repository as `upstream` to your forked repository
4. Add the original n8n repository as `upstream` to your forked repository:
```
git remote add upstream https://github.com/n8n-io/n8n.git
@ -172,13 +172,13 @@ automatically build your code, restart the backend and refresh the frontend
pnpm dev
```
1. Hack, hack, hack
1. Check if everything still runs in production mode
1. Check if everything still runs in production mode:
```
pnpm build
pnpm start
```
1. Create tests
1. Run all [tests](#test-suite)
1. Run all [tests](#test-suite):
```
pnpm test
```
@ -198,7 +198,7 @@ tests of all packages.
## Releasing
To start a release, trigger [this workflow](https://github.com/n8n-io/n8n/actions/workflows/release-create-pr.yml) with the SemVer release type, and select a branch to cut this release from. This workflow will then
To start a release, trigger [this workflow](https://github.com/n8n-io/n8n/actions/workflows/release-create-pr.yml) with the SemVer release type, and select a branch to cut this release from. This workflow will then:
1. Bump versions of packages that have changed or have dependencies that have changed
2. Update the Changelog
@ -206,7 +206,7 @@ To start a release, trigger [this workflow](https://github.com/n8n-io/n8n/action
4. Create a new pull-request to track any further changes that need to be included in this release
Once ready to release, simply merge the pull-request.
This triggers [another workflow](https://github.com/n8n-io/n8n/actions/workflows/release-publish.yml), that will
This triggers [another workflow](https://github.com/n8n-io/n8n/actions/workflows/release-publish.yml), that will:
1. Build and publish the packages that have a new version in this release
2. Create a new tag, and GitHub release from squashed release commit
@ -226,4 +226,4 @@ That we do not have any potential problems later it is sadly necessary to sign a
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 only 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.
Once a pull request is opened, an automated bot will promptly leave a comment requesting the agreement to be signed. The pull request can only be merged once the signature is obtained.

54
packages/node-dev/README.md
View file

@ -48,13 +48,13 @@ all the basics.
A n8n node is a JavaScript file (normally written in TypeScript) which describes
some basic information (like name, description, ...) and also at least one method.
Depending on which method got implemented defines if it is a a regular-, trigger-
Depending on which method gets implemented defines if it is a regular-, trigger-
or webhook-node.
A simple regular node which:
- defines one node property
- sets its value do all items it receives
- sets its value to all items it receives
would look like this:
@ -121,34 +121,34 @@ export class MyNode implements INodeType {
```
The "description" property has to be set on all nodes because it contains all
the base information. Additionally do all nodes have to have exactly one of the
the base information. Additionally all nodes have to have exactly one of the
following methods defined which contains the actual logic:
**Regular node**
Method get called when the workflow gets executed
Method is called when the workflow gets executed
- `execute`: Executed once no matter how many items
- `executeSingle`: Executed once for every item
By default always `execute` should be used especially when creating a
third-party integration. The reason for that is that it is way more flexible
and allows to, for example, return a different amount of items than it received
as input. This is very important when a node should query data like _return
all users_. In that case, does the node normally just receive one input-item
but returns as many as users exist. So in doubt always `execute` should be
used!
By default, `execute` should always be used, especially when creating a
third-party integration. The reason for this is that it provides much more
flexibility and allows, for example, returning a different number of items than
it received as input. This becomes crucial when a node needs to query data such as _return
all users_. In such cases, the node typically receives only one input item but returns as
many items as there are users. Therefore, when in doubt, it is recommended to use `execute`!
**Trigger node**
Method gets called once when the workflow gets activated. It can then trigger
workflow runs which data it provides by itself.
Method is called once when the workflow gets activated. It can then trigger workflow runs and provide the necessary data by itself.
- `trigger`
**Webhook node**
Method gets called when webhook gets called.
Method is called when webhook gets called.
- `webhook`
@ -157,12 +157,12 @@ Method gets called when webhook gets called.
Property overview
- **description** [required]: Describes the node like its name, properties, hooks, ... see `Node Type Description` bellow.
- **execute** [optional]: Method get called when the workflow gets executed (once).
- **executeSingle** [optional]: Method get called when the workflow gets executed (once for every item).
- **execute** [optional]: Method is called when the workflow gets executed (once).
- **executeSingle** [optional]: Method is called when the workflow gets executed (once for every item).
- **hooks** [optional]: The hook methods.
- **methods** [optional]: Additional methods. Currently only "loadOptions" exists which allows loading options for parameters from external services
- **trigger** [optional]: Method gets called once when the workflow gets activated.
- **webhook** [optional]: Method gets called when webhook gets called.
- **trigger** [optional]: Method is called once when the workflow gets activated.
- **webhook** [optional]: Method is called when webhook gets called.
- **webhookMethods** [optional]: Methods to setup webhooks on external services.
### Node Type Description
@ -175,15 +175,15 @@ The following properties can be set in the node description:
- **description** [required]: Description to display users in Editor UI
- **group** [required]: Node group for example "transform" or "trigger"
- **hooks** [optional]: Methods to execute at different points in time like when the workflow gets activated or deactivated
- **icon** [optional]: Icon to display (can be an icon or a font awsome icon)
- **icon** [optional]: Icon to display (can be an icon or a font awesome icon)
- **inputs** [required]: Types of inputs the node has (currently only "main" exists) and the amount
- **outputs** [required]: Types of outputs the node has (currently only "main" exists) and the amount
- **outputNames** [optional]: In case a node has multiple outputs names can be set that users know what data to expect
- **maxNodes** [optional]: If not an unlimited amount of nodes of that type can exist in a workflow the max-amount can be specified
- **outputNames** [optional]: In case a node has multiple outputs, names can be set that users know what data to expect
- **maxNodes** [optional]: If an unlimited number of nodes of that type cannot exist in a workflow, the max-amount can be specified
- **name** [required]: Name of the node (for n8n to use internally, in camelCase)
- **properties** [required]: Properties which get displayed in the Editor UI and can be set by the user
- **subtitle** [optional]: Text which should be displayed underneath the name of the node in the Editor UI (can be an expression)
- **version** [required]: Version of the node. Currently always "1" (integer). For future usage, does not get used yet.
- **version** [required]: Version of the node. Currently always "1" (integer). For future usage, does not get used yet
- **webhooks** [optional]: Webhooks the node should listen to
### Node Properties
@ -203,18 +203,18 @@ The following properties can be set in the node properties:
### Node Property Options
The following properties can be set in the node property options.
The following properties can be set in the node property options:
All properties are optional. However, most only work when the node-property is of a specfic type.
- **alwaysOpenEditWindow** [type: json]: If set then the "Editor Window" will always open when the user tries to edit the field. Helpful if long text is typically used in the property.
- **alwaysOpenEditWindow** [type: json]: If set then the "Editor Window" will always open when the user tries to edit the field. Helpful if long text is typically used in the property
- **loadOptionsMethod** [type: options]: Method to use to load options from an external service
- **maxValue** [type: number]: Maximum value of the number
- **minValue** [type: number]: Minimum value of the number
- **multipleValues** [type: all]: If set the property gets turned into an Array and the user can add multiple values
- **multipleValueButtonText** [type: all]: Custom text for add button in case "multipleValues" got set
- **numberPrecision** [type: number]: The precision of the number. By default it is "0" and will so only allow integers.
- **password** [type: string]: If a password field should be displayed (normally only used by credentials because all node data is not encrypted and get saved in clear-text)
- **multipleValueButtonText** [type: all]: Custom text for add button in case "multipleValues" were set
- **numberPrecision** [type: number]: The precision of the number. By default, it is "0" and will only allow integers
- **password** [type: string]: If a password field should be displayed (normally only used by credentials because all node data is not encrypted and gets saved in clear-text)
- **rows** [type: string]: Number of rows the input field should have. By default it is "1"
## License