Skip to content

Releases: veliovgroup/josk

v5.0.0

10 Apr 22:47
5ad66b1
Compare
Choose a tag to compare

📦 NPM @5.0.0
☄️ Packosphere @5.0.0

What's New

  • 🦄 async/await API for all public methods
  • 🚀 Return {Promise} from tasks instead of calling ready()

Major Changes

  • ⚠️ Drop support for callbacks
  • ⚠️ Renamed private methods for clarity
  • ⚠️ Renamed methods of "Adapter" API for clarity
  • ⚠️ opts.adapter now expects instance of the StorageAdapter, was: Class of StorageAdapter
  • ⚠️ Moved opts.prefix and opts.resetOnInit to StorageAdapter's constructor
  • ⚠️ Moved storage-related options opts.client, opts.db, and lockCollectionName to StorageAdapter's constructor

Changes

  • ✨ New options {object} accepted by new RedisAdapter({})
  • ✨ New options {object} accepted by new MongoAdapter({})
  • 👨‍🔬 Refactored tests for the new async/await API
  • 👨‍🔬 Refactored Meteor.js test-suite for the new async/await API
  • 📔 Updated documentation
  • 📔 Updated custom adapter documentation

v4 to v5 migration

Although setInterval and setTimeout now return {Promise} instead of {String} updated clearInterval and clearTimeout methods accept {Promise}, so migration might not be necessary. Next block of code will remain operational in v3/v4 and v5:

const taskId = job.setInterval((ready) => {
  /* code here */
  ready();
}, 2048, 'task-2048ms');

job.clearInterval(taskId);

Migration is necessary only if callbacks of clearInterval and clearTimeout were used. Callbacks need to get replaced by await. setInterval and setTimeout will require using await to obtain timerId.

was in v3/v4:

const taskId = job.setInterval((ready) => {
  /* code here */
  ready();
}, 2048, 'task-2048ms');

job.clearInterval(taskId, () => {
  // task cleared now
});

change to for v5:

const taskId = await job.setInterval((ready) => {
  /* code here */
  ready();
}, 2048, 'task-2048ms');

await job.clearInterval(taskId);
// task cleared now

Now it's possible to return promises, previously ready() was required to call in v3/v4:

job.setInterval((ready) => {
  /* code here */
  ready();
}, 2048, 'task-2048ms');

now simply register async function in v5:

job.setInterval(async () => {
  /* code here */
}, 2048, 'task-2048ms');

or simply return promise in v5:

job.setInterval(() => {
  /* code here */
  return promisedValue; // instance of the Promise
}, 2048, 'task-2048ms');

or async/await the promise in v5:

job.setInterval(async () => {
  /* code here */
  return await promisedValue;
}, 2048, 'task-2048ms');

now calling ready() inside async function will not work in v5:

job.setInterval(async (ready) => {
  /* code here */
  ready(); // <-- won't run, will log a debug message here
}, 2048, 'task-2048ms');

v4.1.0

08 Apr 21:57
3abac04
Compare
Choose a tag to compare

📦 NPM @4.1.0
☄️ Packosphere @4.1.0

What's new

  • ✨ Added async .ping() method

v4.0.0

04 Apr 23:16
bbdd279
Compare
Choose a tag to compare

📦 NPM @4.0.0
☄️ Packosphere @4.0.0

Major Changes:

  • ⚠️ New way to import and require the package import { JoSk, RedisAdapter, MongoAdapter } from 'josk';
  • ⚠️ Decouple from storage, requires changes in options passed to constructor new JoSk({})
  • 🟥 Added support for Redis as adapter 🥳
  • 🍃 MongoDB as optional adapter 🥳

Changes:

  • 🟥 Added support for Redis, well tested with Redis.io and KeyDB
  • 👨‍💻 Decoupled storage from main codebase
  • ✨ Support for custom storage adapters, see custom adapter documentation
  • opts.adapter {RedisAdapter|MongoAdapter}
  • opts.client {RedisClient}
  • 👨‍🔬 Added tests for Redis
  • 👨‍🔬 Added tests for Redis within Meteor.js
  • 📔 Updated documentation
  • 📔 Created documentation for custom adapter

Dev Dependencies:

  • 📦 chai@5.1.0, was v4.4.1
  • 📦 mocha@10.4.0, was v10.3.0
  • 📦 Added redis@4.6.13

v3.1.1

02 Apr 19:33
0296a0c
Compare
Choose a tag to compare

📦 NPM @3.1.1
☄️ Packosphere @3.1.1

Major Changes:

  • 👨‍🔧 Fix #16 — CommonJS compatibility

Changes:

  • 🤝 Compatibility with ESM and CommonJS import/export, thanks to @masterbater for reporting the issue #16

Dev Dependencies:

  • 📦 bson@6.6.0, was v6.3.0
  • 📦 Removed rudiment dependency pathval, was v2.0.0

v3.1.0

01 Apr 00:22
a0ba80e
Compare
Choose a tag to compare

📦 NPM @3.1.0
☄️ Meteor.js @3.1.0

Major Changes:

  • ⚠️ Minimal required version of Node.js now is @>=14.20.0, was @>=8.9.0
  • 📦 Packaged as ES Module

Changes:

  • 🤝 Compatibility with mongod server, tested with @4.4.29, @5.0.25, @6.0.14, and @7.0.6
  • 🤝 Compatibility with mongodb driver for node.js, tested with @4.17.2, @5.9.2, and @6.5.0
  • 🤝 Compatibility with the latest nodejs releases, tested with @14.21.3, @18.19.1, @20.11.1, and @21.7.1
  • 🤝 Compatibility with the latest Meteor.js and its packages
  • 🤝 Compatibility with upcoming meteor@3.0.0 and its packages

Dev Dependencies:

  • 📦 bson@6.3.0, was v4.6.1
  • 📦 bson-ext@4.0.3, was v4.0.2
  • 📦 chai@4.4.1, was v4.3.6
  • 📦 cron-parser@4.9.0, was v4.5.0
  • 📦 mocha@10.3.0, was v10.0.0
  • 📦 mongodb@6.5.0, was v4.7.0
  • 📦 pathval@2.0.0, was v1.1.1

v3.0.2

03 Jul 12:00
a77c44a
Compare
Choose a tag to compare
  • 👨‍💻 Refactor locking mechanism to avoid dead-locking and minimize DB/Collection locking operations
  • 📔 Update documentation
  • 📦 Run tests with cron-parser@4.5.0
  • 👷‍♂️ Create .meteorignore

v3.0.1

10 Jun 12:18
88c4ce4
Compare
Choose a tag to compare
  • 👨‍💻 Make sure call-check-loop spins even on rare MongoDB errors
  • 🤝 Support meteor@2.7.3

Dependencies:

Development packages used for testing

  • 📦 [dev] bson@4.6.4, was v4.6.3
  • 📦 [dev] mongodb@4.7.0, was v4.6.0

v3.0.0

13 May 04:35
51ff340
Compare
Choose a tag to compare

📦 v3.0.0

Now ☄️ meteor and 📦 NPM follow the same versioning pattern. In this release we have added couple of new features and improved existing codebase.

New features:

  • opts.lockCollectionNamenew JoSk() constructor option
  • opts.debugnew JoSk() constructor option
  • 👨‍💻 ready() — Function passed as an argument to a scheduled task now accepts a callback, see CRON usage example
  • 👨‍💻 JoSk#clearTimeout() and JoSk#clearInterval() — Methods now accept callback as a last argument

Major changes:

  • 👷‍♂️ Now all JoSk instances share the same *.lock collection, this behavior can get changed using opts.lockCollectionName constructor option

Other changes:

  • 📔 Add examples for CRON instructions usage
  • 👨‍🔬 Improve test-cases coverage to 97%
  • 👨‍💻 Overall codebase refactoring and performance improvements
  • 🤝 Compatibility and support of mongod@5.0.8 (Mongo Database)
  • 🤝 Compatibility and support of mongodb@4.6.0 (MongoDB node.js driver)
  • 🤝 Compatibility ans support of meteor@2.7.1

Dependencies:

  • 📦 [dev] mongodb@4.6.0, was v4.5.0
  • 📦 [dev] added cron-parser@4.4.0 for CRON tasks tests

v.2.4.1

05 May 09:41
464a7ad
Compare
Choose a tag to compare
  • ☄️ NPM: v2.4.1
  • 📦 Meteor: v2.6.1

👷‍♂️ This is maintenance release:

  • 🤝 Compatibility with mongodb@4.5.* (Node.js native driver)
  • 🤝 Compatibility with mongod@4.* and mongod@5.* (MongoDB server)
  • 🤝 Compatibility with meteor@2.7.*
  • 👨‍💻 Add in-code documentation
  • 👨‍🔬 Improve test-suite covering 95% cases, closing #7
  • 📔 Improve documentation and examples

Updated dev dependencies:

  • [dev] bson@4.6.3, was v4.2.2
  • [dev] bson-ext@4.0.2, was v2.0.5
  • [dev] chai@4.3.6, was v4.3.0
  • [dev] mocha@10.0.0, was v8.2.1
  • [dev] mongodb@4.5.0, was v3.6.4

v2.4.0

07 Feb 20:45
28a469b
Compare
Choose a tag to compare
  • ☄️ NPM: v2.4.0
  • 📦 Meteor: v2.6.0

Critical Changes:

  • opts.minRevolvingDelay by default 128 ms, was 32;
  • opts.maxRevolvingDelay by default 768 ms, was 256;
  • Default { writeConcern } options removed from write/update operations, pass recommended readConcern, writeConcern, and readPreference as mongodb connections settings;
  • Implement "Collection Locking" via special collection ending with .lock prefix;
  • In total this package will add two new MongoDB collections per each new JoSk({ prefix }) to a database it's connected.

Changes:

  • 🤝 Compatibility with mongodb@3.6.4 (node native driver);
  • 🤝 Compatibility with meteor@2.*;
  • 👨‍💻 Refactor logic and reduce read/write operations;
  • 👷 Stable distictive runs avoiding simultaneous execution across complex multi-server infrastructure;
  • 📋 Documentation update.