starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-26 01:06:00 +03:00

[GH-ISSUE #5073] [feature]: Improve Handling of Duplicate OpenAPI Spec Imports in Hoppscotch #1931

New issue

Open

opened 2026-03-16 22:25:25 +03:00 by kerem · 2 comments

kerem commented

2026-03-16 22:25:25 +03:00

Owner

Originally created by @Leon-Luu on GitHub (May 14, 2025).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5073

Is there an existing issue for this?

I have searched the existing issues

Summary

Problem
Currently, when importing the same OpenAPI specification multiple times in Hoppscotch, the app creates new collections with the same name, based solely on info.title. This leads to confusion and clutter, making it difficult for users to identify the latest or relevant version of the imported spec.

Example:

1st import: "OpenAPI Petstore"

2nd import (same file or version): "OpenAPI Petstore"

3rd import (new version or not): "OpenAPI Petstore"

There is no indication of version, and no safeguards to avoid duplicates or to help the user track versions clearly.

✅ Proposed Solution
When importing an OpenAPI spec:

Check if a collection with the same info.title already exists.

If no collection with the same title exists, proceed with info.title as the collection name (current behavior).

If a collection with the same title exists, enhance naming based on the version from info.version.

Suggested Naming Behavior:
=> First import:

Collection: OpenAPI Petstore

=> Second import of same version (3.0.0):

Option A (default): OpenAPI Petstore[3.0.0]

Option B (if already exists): OpenAPI Petstore[3.0.0] copy

Optional behavior: prompt to overwrite or create copy.

=> Third import with new version (3.0.1):

Collection: OpenAPI Petstore[3.0.1]

Why should this be worked on?

Improves User Experience:
Users frequently re-import updated OpenAPI specs as their APIs evolve. Adding version-aware naming will help users clearly differentiate between versions and reduce accidental usage of outdated collections.

Reduces Clutter & Confusion:
Without unique or versioned names, users may struggle to know which imported collection corresponds to the latest or correct spec, especially in collaborative or long-term projects.

Aligns with Common API Tooling Practices:
Tools like Postman and SwaggerHub already support version tagging or naming differentiation. Bringing this behavior to Hoppscotch will align it with user expectations and best practices.

Scales Better for Teams and CI Pipelines:
In automated or team workflows, the ability to track and overwrite specific versions avoids unnecessary duplication and helps maintain clarity and consistency across environments.

Originally created by @Leon-Luu on GitHub (May 14, 2025). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5073 ### Is there an existing issue for this? - [x] I have searched the existing issues ### Summary **Problem** Currently, when importing the same OpenAPI specification multiple times in Hoppscotch, the app creates new collections with the same name, based solely on info.title. This leads to confusion and clutter, making it difficult for users to identify the latest or relevant version of the imported spec. **Example:** 1st import: "OpenAPI Petstore" 2nd import (same file or version): "OpenAPI Petstore" 3rd import (new version or not): "OpenAPI Petstore" There is no indication of version, and no safeguards to avoid duplicates or to help the user track versions clearly. ![Image](https://github.com/user-attachments/assets/9e15400e-14a8-4907-8d4b-44277b055522) ![Image](https://github.com/user-attachments/assets/598014b9-86ca-4f88-867c-200ca68d7721) ✅ Proposed Solution When importing an OpenAPI spec: Check if a collection with the same info.title already exists. If no collection with the same title exists, proceed with info.title as the collection name (current behavior). If a collection with the same title exists, enhance naming based on the version from info.version. **Suggested Naming Behavior:** => **_First import:_** Collection: OpenAPI Petstore => **_Second import of same version (3.0.0):_** Option A (default): OpenAPI Petstore[3.0.0] Option B (if already exists): OpenAPI Petstore[3.0.0] copy Optional behavior: prompt to overwrite or create copy. => **_Third import with new version (3.0.1):_** Collection: OpenAPI Petstore[3.0.1] ### Why should this be worked on? **Improves User Experience:** Users frequently re-import updated OpenAPI specs as their APIs evolve. Adding version-aware naming will help users clearly differentiate between versions and reduce accidental usage of outdated collections. **Reduces Clutter & Confusion:** Without unique or versioned names, users may struggle to know which imported collection corresponds to the latest or correct spec, especially in collaborative or long-term projects. **Aligns with Common API Tooling Practices:** Tools like Postman and SwaggerHub already support version tagging or naming differentiation. Bringing this behavior to Hoppscotch will align it with user expectations and best practices. **Scales Better for Teams and CI Pipelines:** In automated or team workflows, the ability to track and overwrite specific versions avoids unnecessary duplication and helps maintain clarity and consistency across environments.

kerem added the

feature

label

2026-03-16 22:25:25 +03:00

kerem commented

2026-03-16 22:25:36 +03:00

Author

Owner

@Leon-Luu commented on GitHub (May 15, 2025):

I had created pull request to fix this issue: https://github.com/hoppscotch/hoppscotch/pull/5078

@Leon-Luu commented on GitHub (May 15, 2025): I had created pull request to fix this issue: https://github.com/hoppscotch/hoppscotch/pull/5078

kerem commented

2026-03-16 22:25:41 +03:00

Author

Owner

@Leon-Luu commented on GitHub (May 15, 2025):

Hello @AndrewBastin what do you think about this?

@Leon-Luu commented on GitHub (May 15, 2025): Hello @AndrewBastin what do you think about this?

kerem referenced this issue

2026-03-17 01:10:18 +03:00

[PR #1932] [MERGED] fix: broken PWA install prompt #3568