You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've used Insomnia for a while now - years, but in the last year or so I started using design documents and projects more, as opposed to just having request collections, and found it increasingly difficult to accomplish simple tasks.
One of the things I hit recently is that while it's fairly simple to move/copy requests within a project, the same is surprisingly expensive time-wise between different projects. That is, if I want to split up an existing project and move some of the requests between projects, there is no way to do it because Export/Import is actually implemented as Backup/Restore and imports only go into the original collection. I described this in detail in issue #4283 and will not repeat it here.
The only working alternative for a large number of requests is to export/import HAR traces, which strips off all Insomnia variables and folders, so numerous requests must be edited by hand. Combine this with not being able to select multiple requests in a collection, so they all can be moved into a folder, and you are looking at a long and painful process of moving and editing individual requests. There's also no search and replace to fix all variable references at once.
At some point I noticed a source repository for design documents and got my hopes up that maybe this is the way to convert the proprietary request database into usable files, but it turned out that Insomnia adds the .insomnia directory at the root, where all modifications go. This technique works out for apps that manage entire projects, like GitHub or Visual Studio, but not so much for those who keep Insomnia scripts in DevOps directories in a project tree, along with other scripts, like JMeter, etc.
Committing exported files, as a workaround, also presents a bit of a challenge because there's no Open/Save functionality in the app and Export/Import is not only dangerous in that a script imported from the repository will wipe out local changes of the same script, but also is not secure, because environments are exported as well, along with all secrets, and there's no selection controls in the export dialog to control this. I get it that it wasn't designed for this, but I can't seem to find another way, aside from using Git sync, which is non-starter for me.
I wish there was Open/Save functionality that loads what would look like current Import/Export, except without environments, which would stay where they are today - in a local database. It would also be useful if Export/Import would work like it does it other apps and would allow people to share collections and design docs without being afraid to lose any data - imports would just go into the context collection or design document, with new identifiers as needed. A separate Export/Import for environments would also be useful so they could be copied between different VMs/desktops.
Mind you, this is just my experience, your mileage may vary.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I've used Insomnia for a while now - years, but in the last year or so I started using design documents and projects more, as opposed to just having request collections, and found it increasingly difficult to accomplish simple tasks.
One of the things I hit recently is that while it's fairly simple to move/copy requests within a project, the same is surprisingly expensive time-wise between different projects. That is, if I want to split up an existing project and move some of the requests between projects, there is no way to do it because Export/Import is actually implemented as Backup/Restore and imports only go into the original collection. I described this in detail in issue #4283 and will not repeat it here.
The only working alternative for a large number of requests is to export/import HAR traces, which strips off all Insomnia variables and folders, so numerous requests must be edited by hand. Combine this with not being able to select multiple requests in a collection, so they all can be moved into a folder, and you are looking at a long and painful process of moving and editing individual requests. There's also no search and replace to fix all variable references at once.
At some point I noticed a source repository for design documents and got my hopes up that maybe this is the way to convert the proprietary request database into usable files, but it turned out that Insomnia adds the
.insomniadirectory at the root, where all modifications go. This technique works out for apps that manage entire projects, like GitHub or Visual Studio, but not so much for those who keep Insomnia scripts in DevOps directories in a project tree, along with other scripts, like JMeter, etc.Committing exported files, as a workaround, also presents a bit of a challenge because there's no Open/Save functionality in the app and Export/Import is not only dangerous in that a script imported from the repository will wipe out local changes of the same script, but also is not secure, because environments are exported as well, along with all secrets, and there's no selection controls in the export dialog to control this. I get it that it wasn't designed for this, but I can't seem to find another way, aside from using Git sync, which is non-starter for me.
I wish there was Open/Save functionality that loads what would look like current Import/Export, except without environments, which would stay where they are today - in a local database. It would also be useful if Export/Import would work like it does it other apps and would allow people to share collections and design docs without being afraid to lose any data - imports would just go into the context collection or design document, with new identifiers as needed. A separate Export/Import for environments would also be useful so they could be copied between different VMs/desktops.
Mind you, this is just my experience, your mileage may vary.
Beta Was this translation helpful? Give feedback.
All reactions