Next rebased

.github/workflows/lint-frontend.yml

@@ -36,8 +36,10 @@ jobs:
       - name: Typescript
         run: 'pnpm run lint:tsc'
       - name: Madge
-        run: 'pnpm run lint:madge'
+        run: 'pnpm run lint:dpdm'
       - name: ESLint
         run: 'pnpm run lint:eslint'
       - name: Prettier
         run: 'pnpm run lint:prettier'
+      - name: Knip
+        run: 'pnpm run lint:knip'

Makefile

@@ -6,33 +6,44 @@ default: help
 help:
 	@echo Developer commands:
 	@echo
-	@echo "ruff           Run ruff, fixing any safely-fixable errors and formatting"
-	@echo "ruff-unsafe    Run ruff, fixing all fixable errors and formatting"
-	@echo "mypy           Run mypy using the config in pyproject.toml to identify type mismatches and other coding errors"
-	@echo "mypy-all       Run mypy ignoring the config in pyproject.tom but still ignoring missing imports"
-	@echo "frontend-build Build the frontend in order to run on localhost:9090"
-	@echo "frontend-dev   Run the frontend in developer mode on localhost:5173"
-	@echo "installer-zip  Build the installer .zip file for the current version"
-	@echo "tag-release    Tag the GitHub repository with the current version (use at release time only!)"
+	@echo "ruff              Run ruff, fixing any safely-fixable errors and formatting"
+	@echo "ruff-unsafe       Run ruff, fixing all fixable errors and formatting"
+	@echo "mypy              Run mypy using the config in pyproject.toml to identify type mismatches and other coding errors"
+	@echo "mypy-all          Run mypy ignoring the config in pyproject.tom but still ignoring missing imports"
+	@echo "test"             Run the unit tests.
+	@echo "frontend-install" Install the pnpm modules needed for the front end
+	@echo "frontend-build    Build the frontend in order to run on localhost:9090"
+	@echo "frontend-dev      Run the frontend in developer mode on localhost:5173"
+	@echo "installer-zip     Build the installer .zip file for the current version"
+	@echo "tag-release       Tag the GitHub repository with the current version (use at release time only!)"
 
 # Runs ruff, fixing any safely-fixable errors and formatting
 ruff:
-		ruff check . --fix
-		ruff format .
+	ruff check . --fix
+	ruff format .
 
 # Runs ruff, fixing all errors it can fix and formatting
 ruff-unsafe:
-		ruff check . --fix --unsafe-fixes
-		ruff format .
+	ruff check . --fix --unsafe-fixes
+	ruff format .
 
 # Runs mypy, using the config in pyproject.toml
 mypy:
-		mypy scripts/invokeai-web.py
+	mypy scripts/invokeai-web.py
 
 # Runs mypy, ignoring the config in pyproject.toml but still ignoring missing (untyped) imports
 # (many files are ignored by the config, so this is useful for checking all files)
 mypy-all:
-		mypy scripts/invokeai-web.py --config-file= --ignore-missing-imports
+	mypy scripts/invokeai-web.py --config-file= --ignore-missing-imports
+
+# Run the unit tests
+test:
+	pytest ./tests
+
+# Install the pnpm modules needed for the front end
+frontend-install:
+	rm -rf invokeai/frontend/web/node_modules
+	cd invokeai/frontend/web && pnpm install
 
 # Build the frontend
 frontend-build:

docs/contributing/INVOCATIONS.md

@@ -9,11 +9,15 @@ complex functionality.
 
 ## Invocations Directory
 
-InvokeAI Nodes can be found in the `invokeai/app/invocations` directory. These can be used as examples to create your own nodes.
+InvokeAI Nodes can be found in the `invokeai/app/invocations` directory. These
+can be used as examples to create your own nodes.
 
-New nodes should be added to a subfolder in `nodes` direction found at the root level of the InvokeAI installation location. Nodes added to this folder will be able to be used upon application startup. 
+New nodes should be added to a subfolder in `nodes` direction found at the root
+level of the InvokeAI installation location. Nodes added to this folder will be
+able to be used upon application startup.
+
+Example `nodes` subfolder structure:
 
-Example `nodes`  subfolder structure:
 ```py
 ├── __init__.py # Invoke-managed custom node loader
 │
@@ -30,14 +34,14 @@ Example `nodes`  subfolder structure:
         └── fancy_node.py
 ```
 
-Each node folder must have an `__init__.py` file that imports its nodes. Only nodes imported in the `__init__.py` file are loaded.
- See the README in the nodes folder for more examples: 
+Each node folder must have an `__init__.py` file that imports its nodes. Only
+nodes imported in the `__init__.py` file are loaded. See the README in the nodes
+folder for more examples:
 
 ```py
 from .cool_node import CoolInvocation
 ```
 
-
 ## Creating A New Invocation
 
 In order to understand the process of creating a new Invocation, let us actually
@@ -131,7 +135,6 @@ from invokeai.app.invocations.primitives import ImageField
 class ResizeInvocation(BaseInvocation):
     '''Resizes an image'''
 
-    # Inputs
     image: ImageField = InputField(description="The input image")
     width: int = InputField(default=512, ge=64, le=2048, description="Width of the new image")
     height: int = InputField(default=512, ge=64, le=2048, description="Height of the new image")
@@ -167,7 +170,6 @@ from invokeai.app.invocations.primitives import ImageField
 class ResizeInvocation(BaseInvocation):
     '''Resizes an image'''
 
-    # Inputs
     image: ImageField = InputField(description="The input image")
     width: int = InputField(default=512, ge=64, le=2048, description="Width of the new image")
     height: int = InputField(default=512, ge=64, le=2048, description="Height of the new image")
@@ -197,7 +199,6 @@ from invokeai.app.invocations.image import ImageOutput
 class ResizeInvocation(BaseInvocation):
     '''Resizes an image'''
 
-    # Inputs
     image: ImageField = InputField(description="The input image")
     width: int = InputField(default=512, ge=64, le=2048, description="Width of the new image")
     height: int = InputField(default=512, ge=64, le=2048, description="Height of the new image")
@@ -229,30 +230,17 @@ class ResizeInvocation(BaseInvocation):
     height: int = InputField(default=512, ge=64, le=2048, description="Height of the new image")
 
     def invoke(self, context: InvocationContext) -> ImageOutput:
-        # Load the image using InvokeAI's predefined Image Service. Returns the PIL image.
-        image = context.services.images.get_pil_image(self.image.image_name)
+        # Load the input image as a PIL image
+        image = context.images.get_pil(self.image.image_name)
 
-        # Resizing the image
+        # Resize the image
         resized_image = image.resize((self.width, self.height))
 
-        # Save the image using InvokeAI's predefined Image Service. Returns the prepared PIL image.
-        output_image = context.services.images.create(
-            image=resized_image,
-            image_origin=ResourceOrigin.INTERNAL,
-            image_category=ImageCategory.GENERAL,
-            node_id=self.id,
-            session_id=context.graph_execution_state_id,
-            is_intermediate=self.is_intermediate,
-        )
-
-        # Returning the Image
-        return ImageOutput(
-            image=ImageField(
-                image_name=output_image.image_name,
-            ),
-            width=output_image.width,
-            height=output_image.height,
-        )
+        # Save the image
+        image_dto = context.images.save(image=resized_image)
+
+        # Return an ImageOutput
+        return ImageOutput.build(image_dto)
 ```
 
 **Note:** Do not be overwhelmed by the `ImageOutput` process. InvokeAI has a
@@ -343,27 +331,25 @@ class ImageColorStringOutput(BaseInvocationOutput):
 
 That's all there is to it.
 
-<!-- TODO: DANGER - we probably do not want people to create their own field types, because this requires a lot of work on the frontend to accomodate.
-
 ### Custom Input Fields
 
 Now that you know how to create your own Invocations, let us dive into slightly
 more advanced topics.
 
 While creating your own Invocations, you might run into a scenario where the
-existing input types in InvokeAI do not meet your requirements. In such cases,
-you can create your own input types.
+existing fields in InvokeAI do not meet your requirements. In such cases, you
+can create your own fields.
 
 Let us create one as an example. Let us say we want to create a color input
 field that represents a color code. But before we start on that here are some
 general good practices to keep in mind.
 
-**Good Practices**
+### Best Practices
 
 - There is no naming convention for input fields but we highly recommend that
   you name it something appropriate like `ColorField`.
 - It is not mandatory but it is heavily recommended to add a relevant
-  `docstring` to describe your input field.
+  `docstring` to describe your field.
 - Keep your field in the same file as the Invocation that it is made for or in
   another file where it is relevant.
 
@@ -378,10 +364,13 @@ class ColorField(BaseModel):
     pass
 ```
 
-Perfect. Now let us create our custom inputs for our field. This is exactly
-similar how you created input fields for your Invocation. All the same rules
-apply. Let us create four fields representing the _red(r)_, _blue(b)_,
-_green(g)_ and _alpha(a)_ channel of the color.
+Perfect. Now let us create the properties for our field. This is similar to how
+you created input fields for your Invocation. All the same rules apply. Let us
+create four fields representing the _red(r)_, _blue(b)_, _green(g)_ and
+_alpha(a)_ channel of the color.
+
+> Technically, the properties are _also_ called fields - but in this case, it
+> refers to a `pydantic` field.
 
 ```python
 class ColorField(BaseModel):
@@ -396,25 +385,11 @@ That's it. We now have a new input field type that we can use in our Invocations
 like this.
 
 ```python
-color: ColorField = Field(default=ColorField(r=0, g=0, b=0, a=0), description='Background color of an image')
+color: ColorField = InputField(default=ColorField(r=0, g=0, b=0, a=0), description='Background color of an image')
 ```
 
-### Custom Components For Frontend
-
-Every backend input type should have a corresponding frontend component so the
-UI knows what to render when you use a particular field type.
-
-If you are using existing field types, we already have components for those. So
-you don't have to worry about creating anything new. But this might not always
-be the case. Sometimes you might want to create new field types and have the
-frontend UI deal with it in a different way.
+### Using the custom field
 
-This is where we venture into the world of React and Javascript and create our
-own new components for our Invocations. Do not fear the world of JS. It's
-actually pretty straightforward.
+When you start the UI, your custom field will be automatically recognized.
 
-Let us create a new component for our custom color field we created above. When
-we use a color field, let us say we want the UI to display a color picker for
-the user to pick from rather than entering values. That is what we will build
-now.
--->
+Custom fields only support connection inputs in the Workflow Editor.