will do a separte PR for changes which would require code changes so
it's easier to review , didn't upgrade any deps for `@uppy/aws-s3` since
we'll merge the rewrite so I think we should do that upgrade in the
rewrite branch before merging.
update : Dependency upgrades which required code changes were raised
separately
- #6309
- #6310
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
The `AssemblyInstructionsInput` type from `@transloadit/types` is now
publicly exported from `@uppy/transloadit`, allowing consumers to type
their assembly parameters without importing from the external package.
## Changes
- Re-exported `AssemblyInstructionsInput` type in
`packages/@uppy/transloadit/src/index.ts`
## Usage
```typescript
import type { AssemblyInstructionsInput } from '@uppy/transloadit'
const params: AssemblyInstructionsInput = {
steps: {
encode: {
robot: '/video/encode',
use: ':original',
preset: 'mp4',
},
},
}
```
The type was already imported internally and aliased as
`AssemblyParameters`. This change makes it available to plugin
consumers.
<!-- START COPILOT ORIGINAL PROMPT -->
<details>
<summary>Original prompt</summary>
> Make the AssemblyInstructionsInput type available from the
@uppy/transloadit package by re-exporting it from
packages/@uppy/transloadit/src/index.ts.
>
> Background
> - The Transloadit plugin imports the type AssemblyInstructionsInput
from the external package @transloadit/types and aliases it as
AssemblyParameters in packages/@uppy/transloadit/src/index.ts.
> - Consumers of the @uppy/transloadit package need direct access to the
AssemblyInstructionsInput type but it is not currently exported from the
plugin package.
>
> Change requested
> - Add a type re-export so that consumers can import
AssemblyInstructionsInput from the transloadit plugin package, e.g.
> import type { AssemblyInstructionsInput } from '@uppy/transloadit'
>
> Files to change
> - packages/@uppy/transloadit/src/index.ts
> - Add the following export alongside the other package exports (near
the end of the module where other exports live):
>
> ```typescript name=packages/@uppy/transloadit/src/index.ts
url=https://github.com/transloadit/uppy/blob/main/packages/@uppy/transloadit/src/index.ts
> -export { COMPANION_URL, COMPANION_ALLOWED_HOSTS }
> +export { COMPANION_URL, COMPANION_ALLOWED_HOSTS }
> +
> +// Re-export type from @transloadit/types so callers can import it
from the plugin package.
> +export type { AssemblyInstructionsInput } from '@transloadit/types'
> ```
>
> Notes
> - This is a purely type-only export and should be erased at compile
time; it does not add runtime code.
> - No other behavior or API surface should change.
>
> Please create a branch, apply the change, and open a pull request with
a descriptive title and a short description of the change. Run
TypeScript build checks if available.
>
</details>
<!-- START COPILOT CODING AGENT SUFFIX -->
*This pull request was created from Copilot chat.*
>
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: mifi <402547+mifi@users.noreply.github.com>
Co-authored-by: Mikael Finstad <finstaden@gmail.com>
## Implementation Plan for Transloadit allowMultipleUploadBatches Fix
- [x] Explore the codebase to understand existing structure
- [x] Review transloadit/src/index.ts
- [x] Review existing event handlers (#onError, #onCancelAll)
- [x] Review install() and uninstall() methods
- [x] Understand test structure
- [x] Implement the proper fix in
packages/@uppy/transloadit/src/index.ts
- [x] Set allowNewUpload: false at start of #prepareUpload
(preprocessor)
- [x] Reset allowNewUpload: true at end of #afterUpload (postprocessor)
- [x] Reset allowNewUpload: true in #prepareUpload error handler
- [x] Keep existing resets in #onError and #onCancelAll handlers
- [x] Removed event listener approach (was causing race conditions)
- [x] Update tests to match implementation
- [x] Test allowNewUpload lifecycle through actual upload flow
(preprocessor/postprocessor)
- [x] Test allowNewUpload reset on preprocessor error
- [x] Test allowNewUpload reset on error event
- [x] Test allowNewUpload reset on cancel-all
- [x] Remove obsolete event listener tests
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: mifi <402547+mifi@users.noreply.github.com>
Co-authored-by: Mikael Finstad <finstaden@gmail.com>
Closes#5378
- Introduce `@uppy/image-generator`, a new plugin to generate images
based on a prompt via Transloadit
- until we have "golden templates" the idea is to just send
[steps](https://transloadit.com/docs/topics/templates/#overruling-templates-at-runtime)
- because we must send steps and since we must use signature
authentication for security, which is signed based on the params we
send, we can't reuse the `assemblyOptions` the consumers is already
passing to `@uppy/transloadit` (if they use that uploaders, not needed).
- Remove `SearchInput` (this component was trying to be too many things,
all with conditional boolean props, which is bad practise) in favor of
`useSearchForm` and reuse this hook in two new components `SearchView`
and `FilterInput`
- Reuse all the styles from `SearchProviderView`. This deviates from the
design in #5378. It felt too inconsistent to me to do another UI here
again. For the initial version, I think it's best to stay consistent and
then redesign with search providers taken into account too.
- Because the service is so slow, I went a bit further with the loading
state to show funny messages that rotate while loading mostly because
users will start thinking it is broken after 5 seconds while it fact we
are still loading. But open to ideas here.
This unfortunately means the integration for the consumer is not as lean
and pretty as you would hope. On the upside, it does give them complete
freedom.
```ts
.use(ImageGenerator, {
assemblyOptions: async (prompt) => {
const res = await fetch(`/assembly-options?prompt=${encodeURIComponent(prompt)}`)
return res.json()
}
})
```
on the consumer's server:
```ts
import crypto from 'node:crypto'
const utcDateString = (ms) => {
return new Date(ms)
.toISOString()
.replace(/-/g, '/')
.replace(/T/, ' ')
.replace(/\.\d+Z$/, '+00:00')
}
// expire 1 hour from now (this must be milliseconds)
const expires = utcDateString(Date.now() + 1 * 60 * 60 * 1000)
const authKey = 'YOUR_TRANSLOADIT_KEY'
const authSecret = 'YOUR_TRANSLOADIT_SECRET'
const params = JSON.stringify({
auth: {
key: authKey,
expires,
},
// can not contain any more steps, the only step must be /image/generate
steps: {
generated_image: { // can be named different
robot: '/image/generate',
result: true, // mandatory
aspect_ratio: '2:3', // up to them
model: 'flux-1.1-pro-ultra', // up to them
prompt, // mandatory
num_outputs: 2, // up to them
},
},
})
const signatureBytes = crypto.createHmac('sha384', authSecret).update(Buffer.from(params, 'utf-8'))
// The final signature needs the hash name in front, so
// the hashing algorithm can be updated in a backwards-compatible
// way when old algorithms become insecure.
const signature = `sha384:${signatureBytes.digest('hex')}`
// respond with { params, signature } JSON to the client
```
https://github.com/user-attachments/assets/9217e457-b38b-48ac-81f0-37a417309e98
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Adds AI image generation plugin using Transloadit, exports low-level
Transloadit APIs, and replaces SearchInput with new
FilterInput/SearchView + useSearchForm across provider views.
>
> - **New plugin: `@uppy/image-generator`**
> - UI plugin to generate images from a prompt via Transloadit
(`src/index.tsx`, styles, locale, build configs).
> - Integrated into dev Dashboard and included in `uppy` bundle and
global styles.
> - **Provider Views refactor**
> - Remove `SearchInput`; introduce `useSearchForm`, `SearchView`, and
`FilterInput` components.
> - Update `ProviderView`, `SearchProviderView`, and `Webdav` to use new
components; export them from `@uppy/provider-views`.
> - **Transloadit updates**
> - Export `Assembly`, `AssemblyError`, and `Client` from
`@uppy/transloadit`.
> - Minor internal change: normalize `assemblyOptions.fields`.
> - **Locales**
> - Add strings for image generation and minor additions (e.g.,
`chooseFiles`).
> - Ensure locales build depends on `@uppy/image-generator`.
> - **Build config**
> - Turborepo: add `uppy#build:css` and hook `image-generator` into
locales build.
> - **Changesets**
> - `@uppy/image-generator` major; `@uppy/transloadit` minor;
`@uppy/locales` and `uppy` minor; `@uppy/provider-views` and
`@uppy/webdav` patch.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
4b1b729069. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
---------
Co-authored-by: Prakash <qxprakash@gmail.com>
fixes#6024.
### Problem
- `getPlugin()` defaults to `UnknownPlugin`, so methods like `openModal`
are not visible , since core is not aware of that plugin type
### Proposed change
- Introduce a types-only registry in core:
- `export interface PluginTypeRegistry<M extends Meta, B extends Body>
{}`
- Overload `getPlugin` to return a precise type when the id is a known
key of the registry.
- add `Dashboard` to PluginTypeRegistry through module augmentation:
- `'Dashboard': Dashboard<M, B>`.
- When a project imports from `@uppy/dashboard`, its module augmentation
extends PluginTypeRegistry, adding the correct type into it
- I've added Tests , kept them in a separate file so it's easier to
review , once this approach gets approved I'll add them to
`Uppy.test.ts`
Once this PR gets a positive review I'll add this for other plugins ,
currently only added for `@uppy/dashboard`
**Build with Local tarball can be checked here**
https://stackblitz.com/~/github.com/qxprakash/uppy-type-test?file=type_test.ts
Probably best reviewed commit by commit.
I also split UppyFile into two intefaces distinguished by the `isRemote`
boolean:
- LocalUppyFile
- RemoteUppyFile
Also:
- Removed the TagFile type
- Don't re-upload completed files - fixes#5930
- Clean up stored files on `complete` event *only* if *all* files
succeeded (no failed files). this allows the user to retry failed files
if the browser & upload get interrupted - fixes#5927, closes#5955
- Only set `isGhost` for non-successful files. it doesn't make sense for
successfully uploaded files to be ghosted because they're already done.
#5930fixes#6013
---------
Co-authored-by: Prakash <qxprakash@gmail.com>
## Summary
- ensure the final Transloadit status fetch prefers `assembly_ssl_url`
- add a changeset preparing the patch release
## Testing
- yarn workspace @uppy/transloadit test
The schemas and types that we have in the Transloadit Node.js SDK v4 are
used in our API's system tests. We've also ran hundreds of thousands of
Assemblies through them, ever loosening them, until they all fit. This
means the schemas are fairly wide, but model the reality of our 15 year
old API. In the future we will make schema failures in the API fatal (as
already is the case with system tests), and we don't want to break
production traffic when we do. So we accept wider schemas than are
beautiful, and once the schemas control what is allowed in all places,
we gradually evolve the API and schemas towards being more pretty in
lockstep.
More on this in
https://transloadit.com/blog/2025/09/nodejs-sdk-v4/#our-approach-to-type-retrofitting
For uppy this means, we'll need a few more guards than we had with our
handrolled types, that actually assumed things that turned out to be not
true in all cases. Not all Assembly status responses have an id or a url
for one example. There are for instance particular errors (by Node,
Nginx, Haproxy) that would not return those. The added guards will
ensure we don't break deeply inside customer code.
This PR was completely written by gpt-5-codex, which means it was faster
and of higher quality than if I had handrolled it as a founder
unfamiliar with this codebase, but despite of that, please still review
my contribution with as much care as you would normally :)
---------
Co-authored-by: Mikael Finstad <finstaden@gmail.com>
Co-authored-by: Merlijn Vos <merlijn@soverin.net>
- cleanup `@uppy/utils ` removed unused / redundant modules .
- migrated modules and tests from `.js` to `.ts`
- removed all the nested export paths
- updated `@uppy/utils` import paths for all packages
- `@uppy/angular` is still failing while running`yarn build` , I'm
looking into it.
---------
Co-authored-by: Merlijn Vos <merlijn@soverin.net>
- Remove `e2e` folder entirely
- Remove all hacky resolutions and yarn patches
- Remove `@types/jasmine`, `js2ts` (convert a JS file to TS), and
`vue-template-compiler` from `private/`
- Remove e2e CI job
- Add browsers tests for vue, svelte, and react headless components and
hooks.
- Add new (browser) tests for transloadit, aws-s3, and dashboard.
- Remove final useless scripts from `package.json`, use direct
references in CI.
- Fix Dropzone component accessibility discovered during testing
- Clean up github workflows (move linters.yml into ci.yml, update
e2e.yml)
**Why Vitest Browser Mode?**
We could have used playwright but vitest browser mode uses it under the
hood and we get the use the vitest we know a love. No two entirely
different setups, no different assertions to relearn, write e2e tests as
if you're writing unit tests. Easy, fast, beautiful.
https://vitest.dev/guide/browser/
**Has every single e2e test been rewritten?**
No there were quite a few tests that have a lot overlap with existing or
newly added tests. There were also some tests that were so heavily
mocked inside and out you start to wonder what the value still is. Open
to discuss which tests still need to be added.
* initial poc
* improvements
- split into two plugins
- implement photos picker
- auto login
- save access token in local storage
- document
- handle photos/files picked and send to companion
- add new hook useStore for making it easier to use localStorage data in react
- add new hook useUppyState for making it easier to use uppy state from react
- add new hook useUppyPluginState for making it easier to plugin state from react
- fix css error
* implement picker in companion
* type todo
* fix ts error
which occurs in dev when js has been built before build:ts gets called
* reuse docs
* imrpve type safety
* simplify async wrapper
* improve doc
* fix lint
* fix build error
* check if token is valid
* fix broken logging code
* pull logic out from react component
* remove docs
* improve auth ui
* fix bug
* remove unused useUppyState
* try to fix build error
* fix issue with allowMultipleUploadBatches
fixes#5397
also refactor from promise.then to async/await
and fix what seems like broken logic with recursive this.#afterUpload call
* throw better error when all files have been canceled
after an assembly has been created
also rewrite #createAssembly to async/await
* wait for updateAssembly when restoring
fixes potential race condition
