taskgroup - npm Package Versions

Changes to be impressed by:

• Dramatic performance improvements
  • Improved performance of 10,000 tasks from 13 seconds to 1 seconds
  • Improved memory footprint of 10,000 tasks from 130MB to 4MB (taken during completion event)
• Code has moved from CoffeeScript to ESNext
• Documentation is now powered by JSDoc
• Module is published with Editions

Changes to be cautious about:

• Packaging:
  • require('taskgroup') is no longer the TaskGroup class, you must again do require('taskgroup').TaskGroup
    • It was too difficult to handle this across multiple environments without polluting scopes
• Task and TaskGroup:
  • Once done, the item is now destroyed by default via the destroyOnceDone configuration option
    • This means to add tasks to an already completed TaskGroup, you will need to set destroyOnceDone to false
    • This will be a silent problem, unless coupled with a pauseOnError, onError or onExit deprecation error
  • Running and completed tasks are no longer stored
    • Completed items are now destroyed by default via TaskGroup's destroyDoneItems configuration option
    • If you wish to store them, use the event listeners and disable destroyDoneItems
  • destroy() now operates instantly, including removing all event listeners
    • So if you did .done().destroy().done() the first done listener would be discarded
  • Removed exit() method and exit configuration option
    • They were complex, ambiguous, and undocumented
    • errorOnExcessCompletions and destroyOnceDone configuration options are now provided
  • Replaced onError and pauseOnError configuration options with abortOnError for better clarity
    • Having two or more configuration options for this ability was overly complex
  • Removed sync configuration option
    • It was complex and only had one use case, which turned out was better accomplished without it
  • Renamed includeInResults configuration option to storeResult with improved functionality
    • If destroyOnceDone is true, storeResult will default to false
  • done(), onceDone(), and whenDone() now only listen for upcoming completions, rather than past
    • Listening for past completions was too complex and could never guarantee consistent results
  • timeout configuration option has been removed
    • It is actually best and easily accomplished by your own task methods
  • Removed configuration options will throw deprecation errors to ease migration
• TaskGroup:
  • results state property renamed to result
  • addGroup() method is now addTaskGroup(), alias provided
  • Split nestedConfig configuration option into nestedTaskConfig and nestedTaskGroupConfig

Changes to be aware of:

• Task and TaskGroup:
  • started event has been split into pending and running events for more accurate semantics
  • Less used public APIs have now been marked as private or public depending on their use cases
  • getNames method has been replaced by just names getter, which has its own toString() method that makes use of the nameSeparator configuration option, alias provided
  • getConfig() method now config getter, alias provided
  • isCompleted() method nowcompleted` getter, alias provided
  • hasStarted() method now started getter, alias provided
• TaskGroup:
  • getTotalItems() method now totalItems getter, alias provided
  • getItemTotals() method now `itemTotals getter, alias provided
• Task:
  • If domain configuration option is true and domains are not available, an error will result
  • More accurate error reporting for completion event
    • It a state error occurred, but a argument error did not, it is possible this would not be reported to our done listener, this has been resolved
    • done listener's error argument will now always be the stored error
    • internal result storage now is stored without the error/first argument, as that is stored elsewhere

People to thank:

• Peter Flannery for kickstarting the performance research and making it a priority

Issues closed:

• An unusually large amount of memory usage - issue #19
• Disabled optimisation issue: "bad value context for arguments value - issue #12

• Thanks to kksharma1618 for issue #17
• Closes issue #18

• Thanks to kksharma1618 for issue #17

• We no longer use try...catch at all, if you want error catching in your task, you must not disable domains (they are enabled by default) - why?
• We now force exit the domain when the task's method calls its completion callback
• Domains now wrap only the firing of the task's method, rather than the preparation too as before
• Removed superflous check to ensure a task has a method before execution
• Ensured the actual check to ensure a task has a method before execution also checks if the method is actually a function (via checking for .bind) as the superflous check did

• You may get errors that were suppressed before now showing themselves, this is good, but it may cause unexpected things to break loudly that were breaking silently before
• If you have domains disabled and an error is thrown, you will get a different flow of logic than before as the error will be caught in your code, not TaskGroup's
• The domain's flow has improved, but this may cause a different flow than you were expecting previously

• If you are still on Node v0.8, synchronous errors and perhaps asynchronous errors thrown within your task method will no longer be caught by TaskGroup (due to Node 0.8's crippled domain functionality) and instead will need to be caught by your code either via preferably sent to the task method's completion callback rather than thrown, or via your own try...catch. But please upgrade to Node 0.10 or higher.
• If you are running TaskGroup in a web browser, you will need to catch errors manually or utilise a domain shim (browserify has one by default) - why?