Coder Social home page Coder Social logo

Comments (6)

mdonnalley avatar mdonnalley commented on May 12, 2024 1

@codespool The change that went into 1.9.7 actually fixed the flush functionality. The issue in oclif/oclif#922 was that we weren't awaiting a promise and fixing flush revealed that. You can see the fix here: oclif/oclif#926

I'm assuming that you have a similar issue with your command

from core.

codespool avatar codespool commented on May 12, 2024 1

You could wrap spawn in a promise, listen to exit event, and resolve when it happens. That should play nicely with oclif/core.
We are using it here:
https://github.com/AstarNetwork/swanky-cli/blob/master/src/commands/compile/index.ts

from core.

codespool avatar codespool commented on May 12, 2024

Ah, I see, so pre 1.9.7 tolerates the buggy code, and that's why it works..
Thanks for clearing it up!

from core.

azmuelb avatar azmuelb commented on May 12, 2024

@mdonnalley I'm not sure that's necessarily the same thing. Unless I'm mistaken, the fix applies to a generator issue in the main oclif package, but there's still an issue specifically in oclif/core. Our project is currently hitting this problem, and we're only using oclif/core.

@codespool I know you closed this, but have you checked yet whether it's actually fixed on your end?

from core.

codespool avatar codespool commented on May 12, 2024

Yes, as @mdonnalley hinted, the latest version works when we await the task.run() promise from listr2.

The promise.race in the flush implementation gets passed your command and a timeout of 10s, so if you don't await for a promise inside your command, and it takes more than 10s to resolve, it will throw that timed out error.

So, doesn't matter is it a yeoman generator or something else, as long as you await whatever's promise is running in your Command.run()

from core.

azmuelb avatar azmuelb commented on May 12, 2024

Ah, that makes sense, I misunderstood the root problem earlier. Maybe our case is a bit special then. We have a command that spawns a detached child process with child_process.spawn, and expects the Node process to exit while the child process continues.

So, I'm not sure if this is still a flaw in oclif not handling that scenario, or if this is just an unusual scenario that should be handled differently on our end.

from core.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.