Different results for the same code based on notebook age

I have two notebooks, one older (from sometime in spring 2016 I guess) and one created just yesterday. Both import the icepick library and do some checks. Surprisingly, some of the same checks produce different results, namely a check testing whether icepick.assign always creates a new object or not. Even if I replace the contents of the very first code box with the exact same code:

const i = require('icepick');
const base = { foo: { bar: 'BAZ' } };
base === i.assign(base, {})

the result is different. Since this is a feature that has been changed in the latest release of icepick, I’m guessing that RunKit is somehow caching the versions of imported libraries per notebook. This either needs to be removed, made optional, or at least made transparent.

Hi hon2a,

Let me explain what’s up. When you require a package in a notebook, we shrinkwrap it to that version. That way, if you return a month from now, it won’t update without you realizing. However, if you start a new notebook, we will grab the latest version of that package.

It’s a lot like creating a new project, npm install package. If you return to that project on your hard drive a month from now, it will still use the package from that day. However if you make a new project and npm install package again, it will pull the latest version.

If you go to your old notebook and do require(“icepick/package.json”) you’ll see the version is 1.1.0. If you go to the other one, it is 1.3.0. If in the new notebook you instead require (“icepick@1.1.0”), it will behave the same as the old one. The problem is that we don’t make this obvious so the confusion is completely warranted. We are working on updating the UI to actually SHOW the version currently in use right next to the package, and allow you to change it as well.

If you want to have the new notebook use the OLD package, the process is simple, just require(“icepick@VERSION”).

Hope this helps!

Thanks!

Francisco

Thanks for the explanation!

This makes absolute sense, it’s just a question of transparency. Great to hear you’re already working on that.