Handle kernel serialization

[morenol]

Fixes #221

Checklist

• My branch is up-to-date with development branch.
• Everything works and tested on latest stable Rust.
• Coverage and Linting have been applied

Current behaviour

New expected behaviour

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 44.15%. Comparing base (9eaae9e) to head (f883525).
⚠️ Report is 55 commits behind head on development.

Additional details and impacted files

@@               Coverage Diff               @@
##           development     #232      +/-   ##
===============================================
+ Coverage        43.97%   44.15%   +0.17%     
===============================================
  Files               85       85              
  Lines             7281     7275       -6     
===============================================
+ Hits              3202     3212      +10     
+ Misses            4079     4063      -16     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[morenol]

Wow, typetag is not usable in wasm, I disabled that for WASM32 target. So we have full serialization/deserialization support in all targets except WASM

mmastrac/linktime#14

[Mec-iS]

that is why I wanted default to be empty feature:
default = []
so that it could compiled to Wasm, we can assume that for in-browser application serialisation is not needed in the Wasm binary.

please add some tests for Kernel serialisation/deserialisation

[morenol]

that is why I wanted default to be empty feature: default = [] so that it could compiled to Wasm, we can assume that for in-browser application serialisation is not needed in the Wasm binary.

please add some tests for Kernel serialisation/deserialisation

Addressed.

I agree. I think that by default we should not enable any feature

[morenol]

so that it could compiled to Wasm, we can assume that for in-browser application serialisation is not needed in the Wasm binary.

I think that there could be a couple of use cases in wasm where deserialization could be useful, but I think that is ok for now to partially support WASM

[Mec-iS]

I think that there could be a couple of use cases in wasm where deserialization could be useful, but I think that is ok for now to partially support WASM

yes something we can add later or leave it to the implementation in JS

[Mec-iS]

@morenol please double check that these changes are inline with the new features setup.