Specifically on the jslab kernel (doesn't seem to affect tslab TypeScript kernel), I'm finding that imported/required libraries disappear from scope between cells.
On my current configuration, it seems like this happens for any locally installed library, straight away after the first cell. So for example:
// lodash is in the current folder's ./node_modules
const lodash = require("lodash");
lodash;
console.log("Imported");
[Out 1]: Imported
lodash;
console.log("Still here");
[Out 2]: 1:1 - Cannot find name 'lodash'.
I've also observed that:
Libraries installed further up the directory tree (I'm actually in a container, with some in filesystem root /node_modules) work fine & persist between cells
Likewise built-ins seem OK (like child_process)
In some previous tests, I saw cases where the second cell would be fine but then trying to reference the library in a third cell (e.g. with same contents as [2] above) would cause the issue - but currently not able to reproduce that.
The same issue applies for destructured imports e.g. const { _ } = require("lodash"); or import { _ } from "lodash";
Environment
My setup is actually a bit unusual, and I'm wondering if the different behaviour of local vs FS root dependencies suggests that's a contributing factor in this case.
I'm trying to run tslab 1.0.15 as a custom image (draft Dockerfile here) in Amazon SageMaker Studio, on AWS - which means in practice that:
JupyterLab runs somewhere else, and connects in to the tslab kernel on my custom container
My working folder on the container (/home/sagemaker-user) is mounted to some persistent filesystem somewhere, while the root libraries /node_modules) are the container's native filesystem.
...So I guess there's a chance some fs-events-like monitoring system could be behaving unexpectedly?
Maybe it's related, that I'm also seeing occasional errors like the below when running shell commands via child_process.execSync?
unexpected error: Error: Unexpected pending rebuildTimer
at Object.sys.setTimeout (/usr/lib/node_modules/tslab/dist/converter.js:83:19)
at scheduleProgramUpdate (/usr/lib/node_modules/tslab/node_modules/@tslab/typescript-for-tslab/lib/typescript.js:111417:41)
at onSourceFileChange (/usr/lib/node_modules/tslab/node_modules/@tslab/typescript-for-tslab/lib/typescript.js:111491:13)
at /usr/lib/node_modules/tslab/node_modules/@tslab/typescript-for-tslab/lib/typescript.js:104579:78
at updateContent (/usr/lib/node_modules/tslab/dist/converter.js:568:9)
at Object.convert (/usr/lib/node_modules/tslab/dist/converter.js:218:9)
at Object.execute (/usr/lib/node_modules/tslab/dist/executor.js:140:38)
at JupyterHandlerImpl.handleExecuteImpl (/usr/lib/node_modules/tslab/dist/jupyter.js:219:38)
at /usr/lib/node_modules/tslab/dist/jupyter.js:177:57
at async JupyterHandlerImpl.handleExecute (/usr/lib/node_modules/tslab/dist/jupyter.js:177:21)
Appreciate that if it is specific to my environment then it might be a bit niche... But would be really interested to know if others can reproduce similar on the jslab kernel in other environments!
Specifically on the
jslab
kernel (doesn't seem to affecttslab
TypeScript kernel), I'm finding that imported/required libraries disappear from scope between cells.On my current configuration, it seems like this happens for any locally installed library, straight away after the first cell. So for example:
I've also observed that:
/node_modules
) work fine & persist between cellschild_process
)const { _ } = require("lodash");
orimport { _ } from "lodash";
Environment
My setup is actually a bit unusual, and I'm wondering if the different behaviour of local vs FS root dependencies suggests that's a contributing factor in this case.
I'm trying to run tslab 1.0.15 as a custom image (draft Dockerfile here) in Amazon SageMaker Studio, on AWS - which means in practice that:
tslab
kernel on my custom container/home/sagemaker-user
) is mounted to some persistent filesystem somewhere, while the root libraries/node_modules
) are the container's native filesystem....So I guess there's a chance some
fs-events
-like monitoring system could be behaving unexpectedly?Maybe it's related, that I'm also seeing occasional errors like the below when running shell commands via
child_process.execSync
?Appreciate that if it is specific to my environment then it might be a bit niche... But would be really interested to know if others can reproduce similar on the
jslab
kernel in other environments!