-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Insomnia v4 support for CLI #3055
Insomnia v4 support for CLI #3055
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function uses
doc.type
but the current declaration usesdoc._type
(with the underscore)...
You're definitely on the right track with this.
Lets work with the UnitTest
model for now. When exporting, models.unitTest.type
is translated to EXPORT_TYPE_UNIT_TEST
. It is then set to the property _type
, and the type
property is removed. (I'm not sure why this happens, but it does).
Therefore, when importing, we just need to do the reverse of this. Translate model._type = EXPORT_TYPE_UNIT_TEST
to model.type = 'UnitTest'
(this string value is defined in models.unitTest.type
).
The import logic within the electron app (packages/insomnia-app
) does something like that here then here.
The CLI (packages/insomnia-inso
) cannot import the same logic, but it can also be a lot simpler.
If you do the following two things, you should be up and running again:
- Create a map to translate between the "export" type (
'unit_test'
) and the "model" type ('UnitTest'
) - Use that map to translate between
_type
andtype
in yourextract
method for each model, and delete the_type
property
I think I'm ready for another review. I don't know if I'm missing something else, please point it out as always. Thanks :D |
Great work, will simplify a lot of workflows 🎉 |
@nijikokun we probably need to look at consolidating the Do you have any thoughts about it at this stage, or we roll with introducing a new |
There are a few future concerns I have that I'd like to walk through before making a breaking change to existing flags. Given that we want to support running multiple collections tests at once (entire space) for example what would be the best option. Given the following options:
I will note, I do like the succinctness of So something like Thoughts? |
Yep that's what I'm thinking too. We can definitely work with a single option and try multiple db adapters (in priority) until one works, and I'm liking the succinctness of @MrSnix I'd say we replace In addition we can still keep We can introduce glob support in a future PR since that'll be a little more involved. How does that sound? |
Ok, ready for another review! Changes:
Please, let me know what you think and if I forgot something. (as always :P) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Large review for a large changeset, bear with me! 🤗 Good work with the insomnia adapter 👏🏽
The changes in packages/insomnia-inso/src/db/index.js
in particular are quite tricky to review because of all the rules present and all of the changed unit tests. I don't think it quite matches the current behavior so I have reservations about accepting a large refactor to that file.
If it is possible, my preference would be to stick with the existing logic closely and try fit an extra if
block in the logic to support insomnia export files. There may be some degree of code duplication and that's okay.
But before you embark on another refactor, were you facing issues with the existing logic that pushed you to look at making changes there? Just keen to understand the decision, in case I am missing something. 😄
Smaller commits, longer changeset 😍 Thanks, appreciated.
That's okay. I can revert to the original logic and work on it. 👍🏻 (no prob, really)
Yes, sure.
I hope I clarified my point but I see, in some ways, this is a bit "legacy" so maybe it's better to not alter the current flow. I want to thank you for the time you took to review my code, you so awesome (y), every change was made with the best intention but I'm okay if it is not the right way. Thanks again 😃 and again...and again...and again...
|
As requested: Changes:
Basic question: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost there! 🎉 A couple of observations
I don't know exactly what I have to do when I have a directory of multiple v4.json files, should I merge everything in one big database? Is it correct?
No need to handle that case with this PR (nor do I know the desirable answer to that at this stage, because there are nuances with each approach).
@MrSnix is attempting to deploy a commit to the Insomnia Team on Vercel. A member of the Team first needs to authorize it. |
Any update on this? this PR seems to be pending for a long time |
Hey @abbasc52, sorry about the slow progress with this, it will be merged I just don't have a timeline right now 😞 will see if I can get to having a look at it again in the coming week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re-tested everything and all looks good now. I re-ran linting as it has changed since this was last rebased and also made a very minor adjustment to an error message. thanks again @MrSnix! This is a big one!
I'd like to thank @develohpanda and @dimitropoulos for the support and the time spent with me on reviewing this one: I'm super glad to help this beautiful community. |
Is there going to be a new inso release soon that includes this PR? Building the project myself is easy but an npm release is even easier! |
Hey, @StevenReitsma (and @MrSnix ). We're going to try to get a release out by the end of October. No promises but that's our target right now. Hopefully, we'll have a beta build before that too! |
* Add changes made in this comment: Kong/insomnia#3055 (comment) * Update docs/inso-cli/cli-command-reference/inso-export-spec.md Co-authored-by: lena-larionova <54370747+lena-larionova@users.noreply.github.com> * Update docs/inso-cli/cli-command-reference/inso-export-spec.md Co-authored-by: lena-larionova <54370747+lena-larionova@users.noreply.github.com> * Update options to Global Flags * Add global flags to cli-command-reference * Add global flags to all commands Co-authored-by: lena-larionova <54370747+lena-larionova@users.noreply.github.com>
TL;DR Contributor loses his sanity due to a crash generated by a typo (I presume)
Hi folks, as requested by PR #2666 I'm working on integrating Insomnia v4 support on CLI using a global option to generate an in-memory database that will be available for the lifecycle of the shell itself.
This is an early preview and I'm still working on it⚠️ , I opened it because I feel like I need help 🌊 ⛵ 🌊 with an issue that is raised while delivering the Insomnia DB object to
insomnia-send-request
.I'm using the following command to run the cli while developing from the dist folder:
node inso run test --fromFile ./../src/db/__fixtures__/insomnia-v4/Insomnia.json --verbose
As declared by the spec, I'm using the following Db model:
Sadly, when reaching the following routine, even if I'm delivering the requested model, it dies:
Console Output
After some tests, I was able to figure out that the following parameter
type
is undefined when he reaches this function:After further investigations I found out the problem MAY comes from here:
The function uses
doc.type
but the current declaration usesdoc._type
(with the underscore)...I added the following lines of code on dist.js to check if I was right:
Console Output:
So, I wrote this little function just to check if the real fix was renaming to
type
Sadly it crashes anyway, at the same spot for the same reasons apparently.
MrSnix, can you summarise? Things got complicated.
Well, yes.
Summary:
database.upsert
uses theBaseModel
interface which declarestype
but on my object, I have_type
database.upsert
calldatabase.find(type, db)
withtype = undefined
database.find(type, db)
dies because he tries to accessdb['undefined'].find()
_type
totype
I have no clue what's happening there.
What should I do?
Any idea?
It closes #2666