Causes of "RuntimeError: Attempted to assign to readonly property." when importing Notebook 1.0

[tomlarkworthy]

I run into "RuntimeError: Attempted to assign to readonly property." a fair bit. One cause is mutable variables, they do not import correctlt on Notebook 2.0. But is that the only cause? After eliminating them (and fixing some bugs) I still feel like I am still getting them via some other source. Is mutating an object reference passes through the runtime forbidden?

[mbostock]

We aren’t currently guaranteeing compatibility when importing 1.0 notebooks.

The main issue is that 1.0 notebooks use a older standard library and I don’t want to build the machinery to support multiple simultaneous standard libraries (a different standard library for the main notebook versus imported notebooks).

If this proves to be a frequent stumbling block, it wouldn’t be too hard to find a way to use the old standard library in imported notebooks, though that has its own downsides, such as d3 in the main notebook being loaded via import, while a separate copy of d3 being loaded in imported modules using require. Perhaps easier would be to patch the new standard library to improve compatibility with the old one, or to have some sort of adapter layer when importing 1.0 notebooks. (I’ve done a bit of this already.)

Enumerating all the differences is probably impractical, but I can start by listing some of the bigger known ones:

• require isn’t really supported; it’s just a wrapper on dynamic import, so libraries that support both will work, but libraries that require AMD won’t work, nor will advanced features such as require.alias; require should work for all the recommended libraries, at least
• mutable isn’t supported in imported notebooks because the API of Mutable has changed (there’s now a public API; see the Framework docs for now; see also Mutable cells in classic notebooks with initial value of null cause error #21); however, you can use mutable in OJS cells, so you could copy-paste code as a workaround perhaps
• Recommended libraries are now (with a continued exception for DuckDB-Wasm’s broken dist tag) the latest versions from npm by default
• A handful of long-deprecated standard library methods have been removed; see the Framework docs, although I have added a few of these back to improve compatibility

If you want to share a reproduction, I’d be happy to investigate and give a more precise cause. I can’t say from the error message alone what the cause is.

[mootari]

Would it be feasible (and practical) for some of these to require authors to explicitly opt into compatibility layers via import attributes?

[mbostock]

I’d rather focus on incremental changes we can make to improve backwards compatibility in the current standard library.