senecajs
old configs don't work anymore, consider releasing a major version due to breaking changes?
We just noticed there was some movement after an eternity :p
however the latest changes break things quite horribly. We get tons of errors and crashes, so I guess you should consider releasing a version 4 unless this wasn't intended:
Here a crash example:
GubuError: Validation failed for object "{log:silent,actcache:{activ..." because the properties "actcache, seneca" are not allowed
btw. the new typescript version is quite slower than the old js version. so this switch comes with a downgrade :/
@wzrdtales this is a bug - thanks! 3.x should remain compatible - will update
@wzrdtales we are preparing for Seneca 4.x - please DM on twitter or linkedin would like to make sure this is mostly painless for you but will need to understand what you are using
pinged you on linkedin, but you can just hit me a mail as well its public on my github profile
and slower: everything. dramatically. In Process calls are 44+% (40k vs 62k before per process) slower. Remote as well (7k vs 11k per process). We hard forked seneca for now should we want to make hotfixes, but that should be just a temporary thing. We have applications that hit those limits of requests per second pretty hard, so that is a show stopper for us and naturally we went back to status quo. Just tested with the latest version, same same, still significantly slower.
Dug through the code a little bit, this message is returned by "gubu" which seems to do message validation now.
I found it can be disabled by applying the following legacy options:
legacy: { rules: true },
Relevant comments from the code,
// If false, use Gubu for message validation.
rules: false,
// If false, use Gubu for option validation (including plugin defaults)
options: true,
I'd think "rules" should default to "true" for a non-breaking change?
I can also confirm at least one performance issue. Looks like this was introduced between 3.16.0 => 3.17.0
Our tests use a beforeEach hook to initialize seneca, add a bunch of plugins and call seneca.ready(done)
$ npm i [email protected] && time npm test
real 0m2.566s
user 0m3.059s
sys 0m0.224s
$ npm i [email protected] && time npm test
real 0m19.922s
user 0m6.289s
sys 0m0.388s
$ npm i seneca@latest && time npm test
real 0m20.610s
user 0m7.340s
sys 0m0.373s
The beforeEach hooks go from ~10ms to ~150ms (measured with console.time & console.timeEnd). The actual tests themselves don't seem affected and complete sub 10ms. Going to need to do some stress tests to see if runtime is affected... (in the midst of updating an ancient seneca version to latest and found this). 3.29.0 is comparable to 3.17.0
will conduct another performance test with the latest changes soon @rjrodger