This plugin does not seem to work well with tw v4. Can revert this PR
later.
---
the graph is forcing tailwind-api-utils@1.0.3 which tries to import v3
files, or something like that.
```
> @comfyorg/comfyui-frontend@1.31.0 lint:fix /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31
> eslint src --cache --fix
Oops! Something went wrong! :(
ESLint: 9.35.0
Error: Error while loading rule 'tailwindcss/enforces-negative-arbitrary-values': Cannot find module '/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/tailwindcss@4.1.12/node_modules/tailwindcss/dist/lib/setupContextUtils.js'
Require stack:
- /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/tailwind-api-utils@1.0.3_tailwindcss@4.1.12/node_modules/tailwind-api-utils/dist/index.cjs
- /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/eslint-plugin-tailwindcss@4.0.0-beta.0_tailwindcss@4.1.12/node_modules/eslint-plugin-tailwindcss/lib/util/customConfig.js
- /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/eslint-plugin-tailwindcss@4.0.0-beta.0_tailwindcss@4.1.12/node_modules/eslint-plugin-tailwindcss/lib/util/tailwindAPI.js
- /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/eslint-plugin-tailwindcss@4.0.0-beta.0_tailwindcss@4.1.12/node_modules/eslint-plugin-tailwindcss/lib/rules/classnames-order.js
- /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/eslint-plugin-tailwindcss@4.0.0-beta.0_tailwindcss@4.1.12/node_modules/eslint-plugin-tailwindcss/lib/index.js
Occurred while linting /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/src/base/common/downloadUtil.ts
at Module._resolveFilename (node:internal/modules/cjs/loader:1410:15)
at defaultResolveImpl (node:internal/modules/cjs/loader:1051:19)
at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1056:22)
at Module._load (node:internal/modules/cjs/loader:1219:37)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:238:24)
at Module.require (node:internal/modules/cjs/loader:1493:12)
at require (node:internal/modules/helpers:152:16)
at TailwindUtils.loadConfigV3 (/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/tailwind-api-utils@1.0.3_tailwindcss@4.1.12/node_modules/tailwind-api-utils/dist/index.cjs:429:31)
at getTailwindConfig (/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/eslint-plugin-tailwindcss@4.0.0-beta.0_tailwindcss@4.1.12/node_modules/eslint-plugin-tailwindcss/lib/util/tailwindAPI.js:14:11)
ELIFECYCLE Command failed with exit code 2.
```
This pull request refactors how context menu items are contributed by
extensions in the LiteGraph-based canvas. The legacy monkey-patching
approach for adding context menu options is replaced by a new, explicit
API (`getCanvasMenuItems` and `getNodeMenuItems`) for extensions. A
compatibility layer is added to support legacy extensions and warn
developers about deprecated usage. The changes improve maintainability,
extension interoperability, and migration to the new context menu
system.
### Context Menu System Refactor
* Introduced a new API for extensions to contribute context menu items
via `getCanvasMenuItems` and `getNodeMenuItems` methods, replacing
legacy monkey-patching of `LGraphCanvas.prototype.getCanvasMenuOptions`.
Major extension files (`groupNode.ts`, `groupOptions.ts`,
`nodeTemplates.ts`) now use this new API.
[[1]](diffhunk://#diff-b29f141b89433027e7bb7cde57fad84f9e97ffbe5c58040d3e0fdb7905022917L1779-R1771)
[[2]](diffhunk://#diff-91169f3a27ff8974d5c8fc3346bd99c07bdfb5399984484630125fdd647ff02fL232-R239)
[[3]](diffhunk://#diff-04c18583d2dbfc013888e4c02fd432c250acbcecdef82bf7f6d9fd888e632a6eL447-R458)
* Added a compatibility layer (`legacyMenuCompat` in
`contextMenuCompat.ts`) to detect and warn when legacy monkey-patching
is used, and to extract legacy-added menu items for backward
compatibility.
[[1]](diffhunk://#diff-2b724cb107c04e290369fb927e2ae9fad03be9e617a7d4de2487deab89d0d018R2-R45)
[[2]](diffhunk://#diff-d3a8284ec16ae3f9512e33abe44ae653ed1aa45c9926485ef6270cc8d2b94ae6R1-R115)
### Extension Migration
* Refactored core extensions (`groupNode`, `groupOptions`, and
`nodeTemplates`) to implement the new context menu API, moving menu item
logic out of monkey-patched methods and into explicit extension methods.
[[1]](diffhunk://#diff-b29f141b89433027e7bb7cde57fad84f9e97ffbe5c58040d3e0fdb7905022917L1633-L1683)
[[2]](diffhunk://#diff-91169f3a27ff8974d5c8fc3346bd99c07bdfb5399984484630125fdd647ff02fL19-R77)
[[3]](diffhunk://#diff-04c18583d2dbfc013888e4c02fd432c250acbcecdef82bf7f6d9fd888e632a6eL366-R373)
### Type and Import Cleanup
* Updated imports for context menu types (`IContextMenuValue`) across
affected files for consistency with the new API.
[[1]](diffhunk://#diff-b29f141b89433027e7bb7cde57fad84f9e97ffbe5c58040d3e0fdb7905022917R4-L7)
[[2]](diffhunk://#diff-91169f3a27ff8974d5c8fc3346bd99c07bdfb5399984484630125fdd647ff02fL1-R11)
[[3]](diffhunk://#diff-04c18583d2dbfc013888e4c02fd432c250acbcecdef82bf7f6d9fd888e632a6eL2-R6)
[[4]](diffhunk://#diff-bde0dce9fe2403685d27b0e94a938c3d72824d02d01d1fd6167a0dddc6e585ddR10)
### Backward Compatibility and Migration Guidance
* The compatibility layer logs a deprecation warning to the console when
legacy monkey-patching is detected, helping developers migrate to the
new API.
---
These changes collectively modernize the context menu extension
mechanism, improve code clarity, and provide a migration path for legacy
extensions.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5993-Contextmenu-extension-migration-2876d73d3650813fae07c1141679637a)
by [Unito](https://www.unito.io)
---------
Co-authored-by: github-actions <github-actions@github.com>
## Summary
The private fields triggered an error in intitializing the
linkLayoutSync. Turns out that wasn't necessary anymore.
> [!NOTE]
> Edit: Doing some more investigation, it looks like the slot sync can
also be removed?
## Changes
- **What**: Converts JS private fields to typescript private, adds some
readonly declarations
- **What**: Removes the useLinkLayoutSync usage in useVueNodeLifecycle
- **What**: Removes the useSlotLayoutSync usage in useVueNodeLifecycle
## Review Focus
Was the sync doing something that wouldn't be caught in normal
usage/testing?
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6330-Fix-Vue-Litegraph-conversion-bug-with-Reroutes-2996d73d3650819ebb24e4aa2fc51c65)
by [Unito](https://www.unito.io)
## Summary
Make some settings dynamic based on whether in cloud or localhost
1. Comfy.Memory.AllowManualUnload (line 18-24)
- Type: 'hidden' on cloud, 'boolean' on localhost
- Default: false on cloud, true on localhost
2. Comfy.Validation.Workflows (line 25-30)
- Default: false on cloud, true on localhost
3. Comfy.Workflow.ShowMissingModelsWarning (line 282-288)
- Type: 'hidden' on cloud, 'boolean' on localhost
- Default: false on cloud, true on localhost
4. Comfy.ModelLibrary.AutoLoadAll (line 387-394)
- Type: 'hidden' on cloud, 'boolean' on localhost
5. Comfy.QueueButton.BatchCountLimit (line 595-603)
- Default: 4 on cloud, 100 on localhost
6. Comfy.Toast.DisableReconnectingToast (line 943-949)
- Default: true on cloud, false on localhost
7. Comfy.Assets.UseAssetAPI (line 1068-1075)
- Default: true on cloud, false on localhost
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6302-change-some-settings-for-cloud-specific-behavior-2986d73d365081169be4ebd11823a7fa)
by [Unito](https://www.unito.io)
## Summary
Create display priority based on execution success timestamps.
Next up is displaying in progress prompts in the queue.
## Review Focus
@DrJKL and I discussed logic and decided for history, execution success
(when the prompt finishes) is the best way to assign priority.
This does differ from existing cloud logic which uses execution start
time.
For prompt progress I intend to create a priority for them based on
start time.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6336-feat-historyV2-create-sythetic-queue-priority-2996d73d365081ffa3a0f8071c178066)
by [Unito](https://www.unito.io)
## Summary
Changed history reconciliation to use `promptId` instead of `queueIndex`
to support cloud environments that don't have queue indices.
Refactored into pure functions with expressive naming.
## Changes
- Use `promptId` (unique UUID) for reconciliation instead of
`queueIndex` (not available in cloud)
- Extract `reconcileHistoryWithServer` with helpers: `extractPromptIds`,
`isAddedAfter`, `sortNewestFirst`
- Added 34 tests covering reconciliation edge cases, sorting, and limits
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6327-use-prompt-id-rather-than-queue-index-for-history-reconciliation-2996d73d3650818e9471dbeb53cc23bb)
by [Unito](https://www.unito.io)
Follow up on https://github.com/Comfy-Org/ComfyUI_frontend/pull/6317:
Fixes confusing "merge conflicts detected" message when commit already
exists on target branch (e.g., PRs #6294 and #6307).
## Changes
- Added check to detect if merge commit already exists on target branch
before attempting cherry-pick
- New failure reason `already-exists` for this case
- Clear comment message: "Commit already exists on branch, no backport
needed" instead of confusing "Merge conflicts detected" with empty file
list
## Before
When a commit already existed on the target branch, users would see:
> @user Backport to `core/1.30` failed: Merge conflicts detected.
> Please manually cherry-pick commit `abc123` to the `core/1.30` branch.
> <details><summary>Conflicting files</summary>
>
> </details>
This was confusing because there were no actual conflicts - the commit
was already present.
## After
Users now see:
> @user Commit `abc123` already exists on branch `core/1.30`. No
backport needed.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6326-ci-leave-comment-and-abort-early-if-commit-already-exists-on-target-branch-in-backport-w-2996d73d36508167aff3e6783e832c74)
by [Unito](https://www.unito.io)
Changes the RC minor version branch release automation to create paired
`core/x.y` and `cloud/x.y` branches whenever a release bump merges.
Then changes the backport workflow to accept labels that match those
branch names directly, allowing engineers to route fixes to either OSS
or cloud release lines without extra labels or artifacts.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6321-ci-automate-cloud-release-branch-tagging-2996d73d365081b0b036ebd3f088354b)
by [Unito](https://www.unito.io)
## Summary
This PR fixes all @intlify/vue-i18n/no-raw-text linting errors
identified in #5625 by replacing raw text strings with proper i18n
translation function calls.
## Changes
Fixed i18n linting errors in the following files:
- `src/components/widget/SampleModelSelector.vue` - "Upload Model" →
`$t('g.upload')`
- `src/components/topbar/CurrentUserButton.vue` - "user profile" →
`$t('g.currentUser')`
- `src/components/sidebar/tabs/nodeLibrary/NodeHelpPage.vue` - "Loading
help" → `$t('g.loading')`
- `src/components/sidebar/SidebarShortcutsToggleButton.vue` -
"shortcuts.shortcuts" → `$t('shortcuts.shortcuts')`
- `src/components/sidebar/SidebarLogoutIcon.vue` - "sideToolbar.logout"
→ `$t('sideToolbar.logout')`
- `src/components/sidebar/SidebarHelpCenterIcon.vue` - "menu.help" →
`$t('menu.help')`
- `src/components/sidebar/SidebarBottomPanelToggleButton.vue` -
"sideToolbar.labels.console" → `$t('sideToolbar.labels.console')`
- `src/components/load3d/controls/viewer/ViewerCameraControls.vue` -
"fov" → `t('load3d.fov')`
- `src/components/helpcenter/HelpCenterMenuContent.vue` - "Help Center
Menu" and "Recent releases" → `$t()` calls
All raw text strings have been replaced with appropriate i18n
translation keys that already exist in `src/locales/en/main.json`.
## Related Issue
Fixes errors reported in CI job:
https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18705105609/job/53341658467?pr=5625
This PR aims to help #5625 pass CI/CD checks.
## Test Plan
- All i18n linting errors should be resolved
- No functionality changes - only proper use of i18n system
- Existing translation keys are used from the locale files
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6280-bugfix-fix-intlify-vue-i18n-no-raw-text-linting-errors-2976d73d365081369b43de01486fb409)
by [Unito](https://www.unito.io)
---------
Co-authored-by: GitHub Action <action@github.com>
## Summary
Fixes `trackTemplate` calls to use raw template ID instead of translated
workflow name for analytics tracking.
## Problem
When users load templates with non-English locale, the `workflow_name`
field was being tracked in their language (e.g., "默认工作流" for Chinese
users) instead of English. This makes statistical analysis difficult.
## Changes
- Updated both `trackTemplate` calls in `useTemplateWorkflows.ts` to use
raw `id` instead of translated `workflowName`
- The translated name is still used for display purposes in
`loadGraphData`
**Before:**
```typescript
useTelemetry()?.trackTemplate({
workflow_name: workflowName, // Could be "默认工作流"
template_source: sourceModule
})
```
**After:**
```typescript
useTelemetry()?.trackTemplate({
workflow_name: id, // Always "default"
template_source: sourceModule
})
```
## Testing
- [x] Type checking passes
- [x] Verified translated names still used for display
## Related
Part of comprehensive i18n audit for telemetry tracking. Related to
template metadata English tracking in PR #6304.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6320-bugfix-use-raw-template-ID-for-workflow_name-in-telemetry-tracking-2996d73d365081d8aef3fa2529a10247)
by [Unito](https://www.unito.io)
## Summary
Expands the wait step in `pr-claude-review.yaml` so the
`lewagon/wait-on-check-action` accepts every terminal GitHub conclusion
instead of failing on outcomes like cancelled or failure. After the wait
completes, the `check-status` script still inspects those check runs and
only marks `should-proceed=true` when the tracked jobs finished
successfully.
Fixes what happened here:
https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18828179272/job/53714488799?pr=6298
## Summary
Updates `SurveyResponses` interface to match actual survey fields 1-to-1
based on analytics requirements.
## Changes
- Remove `team_size` property (no corresponding survey question exists)
- Change `use_case` to `useCase` to match actual survey field name
- Remove `intended_use` property (doesn't exist in actual survey)
- Add `making` field array for content generation type tracking (video,
image, etc.)
This fixes a Mixpanel analytics issue where survey properties weren't
mapping 1-to-1 with actual survey questions, making statistical analysis
difficult.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6314-bugfix-fix-survey-properties-mapping-to-match-actual-survey-data-2996d73d36508158a335e6b73e3e14ef)
by [Unito](https://www.unito.io)
## Summary
Split mask editor structure into smaller files
## Changes
This PR is a prerequisite step for [the issue - refactoring the mask
editor using
Vue](https://github.com/Comfy-Org/ComfyUI_frontend/issues/5956). It
splits the current monolithic maskeditor.ts (about 5700 lines) into
separate files; otherwise, the original single file would be very
difficult to analyze or maintain.
This PR itself does not introduce any Vue, nor should it have any
functional changes or modifications. It's purely a code-level split,
with all related files placed in the maskeditor folder.
The original maskeditor.ts has been renamed to maskeditor.ts.backup for
future reference.
## Review Focus
Since this PR is only for splitting purposes, all logic remains
consistent with the original. Therefore, for any reviewer: any code
logic improvements should happen in the subsequent Vue-based
refactoring, not in this PR.
Following this PR, I will perform a Vue-based refactoring of the mask
editor to align with the frontend's overall Vue architecture and provide
better cloud-related support.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6308-refactor-Split-mask-editor-into-smaller-files-2986d73d36508131937dd43e465a47bd)
by [Unito](https://www.unito.io)
## Summary
Track template metadata in English for analytics regardless of user's
locale to enable consistent statistical analysis.
## Changes
- **What**: Load English [template
index](https://github.com/Comfy-Org/ComfyUI_frontend/tree/main/public/templates)
alongside localized version (cloud builds only)
- **What**: Added `getEnglishMetadata()` method to
`workflowTemplatesStore` that returns English versions of template tags,
category, useCase, models, and license
- **What**: Updated `MixpanelTelemetryProvider` to prefer English
metadata for analytics events, falling back to localized values
## Review Focus
English template fetch only triggers in cloud builds via `isCloud` flag.
Non-cloud builds see no bundle size impact. Method returns null when
English templates unavailable, with fallback to localized data ensuring
analytics continue working in edge cases.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6292-translate-all-analytics-to-English-for-template-metadata-2986d73d365081fdbc21f372aa9bb41e)
by [Unito](https://www.unito.io)
---------
Co-authored-by: github-actions <github-actions@github.com>
## Summary
Backport outputs from new cloud history endpoint
Does:
1. Show history in the Queue
2. Show outputs from prompt execution
Does not:
1. Handle appending latest images generated to queue history
2. Making sure that workflow data from images is available from load
(requires additional API call to fetch)
Most of this PR is:
1. Test fixtures (truncated workflow to test).
2. The service worker so I could verify my changes locally.
## Changes
- Add `history_v2` to `history` adapter
- Add tests for mapping
- Do branded validation for promptIds (suggestion from @DrJKL)
- Create a dev environment service worker so we can view cloud hosted
images in development.
## Review Focus
1. Is the dev-only service work the right way to do it? It was the
easiest I could think of.
4. Are the validation changes too heavy? I can rip them out if needed.
## Screenshots 🎃https://github.com/user-attachments/assets/1787485a-8d27-4abe-abc8-cf133c1a52aa
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6288-Feat-history-v2-outputs-2976d73d365081a99864c40343449dcd)
by [Unito](https://www.unito.io)
---------
Co-authored-by: bymyself <cbyrne@comfy.org>
## Summary
Fixes Pinia initialization error that occurred when the auth service
worker tried to access stores before Pinia was set up.
## Problem
The auth service worker was being imported at the top of `main.ts`,
causing it to register immediately:
```typescript
import '@/platform/auth/serviceWorker' // Runs immediately on import
```
This happened before Pinia was initialized, causing an error when the
service worker setup tried to use stores:
```
Error: [🍍]: "getActivePinia()" was called but there was no active Pinia.
```
## Solution
Moved the service worker registration to after Pinia is set up but
before mounting the app:
```typescript
.use(pinia)
.use(i18n)
.use(VueFire, {
firebaseApp,
modules: [VueFireAuth()]
})
// Register auth service worker after Pinia is initialized (cloud-only)
if (isCloud) {
void import('@/platform/auth/serviceWorker')
}
app.mount('#vue-app')
```
## Benefits
- ✅ Pinia stores are available when service worker setup runs
- ✅ Still tree-shaken for non-cloud builds via dynamic import in `if
(isCloud)`
- ✅ Registers before mounting, so service worker is active from the
start
## Testing
- Verified no Pinia errors in cloud builds
- Verified tree-shaking still works (service worker code not in
localhost builds)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6272-bugfix-fix-service-worker-registration-timing-to-run-after-Pinia-setup-2976d73d365081b998dfd2eded782070)
by [Unito](https://www.unito.io)
## Summary
Removes the checkbox from the sign up form to simplify the user
experience. The "By clicking 'Next' or 'Sign Up'..." notice at the
bottom already covers terms and privacy.
## Changes
- Removed checkbox field from sign up schema
- Updated `SignUpForm.vue` component
- Removed unused `Checkbox` import
## Before/After
**Before:**
Sign up form included a checkbox that users had to check before
submitting
**After:**
Sign up form is cleaner without the checkbox. The existing notice text
covers the same information:
> "By clicking 'Next' or 'Sign Up', you agree to our Terms of Use and
Privacy Policy."
This notice appears on both sign in and sign up modals.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6269-remove-checkbox-from-sign-up-form-2976d73d3650819ab480e4db6685baee)
by [Unito](https://www.unito.io)
## Summary
Fixes CORS errors in HTTPS environments where the auth service worker
blocked cross-origin redirects to Google Cloud Storage.
## Problem
The service worker was using `mode: 'same-origin'` which prevented
following redirects when `/api/view` returns a 302 redirect to GCS:
```
Unsafe attempt to load URL https://storage.googleapis.com/...
from frame with URL https://testcloud.comfy.org/auth-sw.js.
Domains, protocols and ports must match.
```
This only occurred in HTTPS/cloud environments where media is served
from GCS. Localhost/HTTP test environments serve files directly without
redirects, so the issue wasn't caught there.
## Solution
Changed redirect handling from automatic to manual:
1. **Initial request to `/api/view`**: Sends WITH auth headers
(validates user access)
2. **Detect redirect response**: Checks for 301/302/opaqueredirect
3. **Follow redirect to GCS**: Fetches WITHOUT auth headers (signed URL
has built-in auth)
### Key Changes
- Removed `mode: 'same-origin'` (was blocking cross-origin redirects)
- Changed `redirect: event.request.redirect` to `redirect: 'manual'`
- Added manual redirect handling that follows to GCS without Firebase
auth headers
## Why This Works
The two requests have different authentication mechanisms:
- **`/api/view` request**: Uses Firebase auth header (backend validates
user access)
- **GCS request**: Uses signed URL with query params (`Signature=...`,
`GoogleAccessId=...`, `Expires=...`)
The security check still happens on the initial `/api/view` request, but
we allow the redirect to GCS to use its own authentication system.
## Testing
- Typecheck passed
- Should be tested in HTTPS cloud environment with media files stored in
GCS
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6265-bugfix-fix-auth-service-worker-to-handle-cross-origin-redirects-to-GCS-2976d73d365081d0b124db4918f8194e)
by [Unito](https://www.unito.io)
`LLink.disconnect` is intended to cleanup only the link itself. #4800
mistakenly assumed that it would perform all required steps for
disconnection. Later, #5015 would partially resolve this by adding some
of the missing functionality into `LLink.disconnect`, but this still
left output cleanup unhandled and failed to call
`node.onConnectionsChanged`.
This PR instead moves the disconnection code to call the function that
already has robust handling for these items and removes the
no-longer-needed and potentially misleading workaround.
Resolves#6247
Also un-skipped several SubgraphIO tests. They appear to function fine.
I'm assuming the reasons for them being skipped have been resolved.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6258-Fix-disconnection-of-subgraphInput-links-2966d73d36508112ad1fe602cdcf461b)
by [Unito](https://www.unito.io)
