Update to JLab 1.0RC #2456
Update to JLab 1.0RC #2456
Conversation
(and pull in the full jlab updates)
|
Widgets now work in JupyterLab (at least the int slider). They don't work in classic because I've changed Typescript to generate es2017, and the classic widget manager is not using classes. To fix classic notebook, we should change the classic notebook widget manager to be a proper es6 class (we don't need to move to typescript, a plain js class would work just fine). |
|
@SylvainCorlay - do you want to take this over? I'm not sure when I'll be able to get back to it. |
This fixes errors in the classic notebook extension of trying to extend a proper class with a function.
|
is this error with jlab-1.0.0rc0 related to this ? |
|
Maybe? Widgets has not been updated for rc0 yet. I don't know what error you're seeing there, but widgets won't work yet. |
tmpnb has been retired, so this example should not work.
…easily inspect the js.
|
Okay, I think I checked that each of the examples works now. I deleted the tmpnb example since tmpnb is no more. |
|
FYI, this will require a major bump of each js npm package (but not a major bump of ipywidgets python package). |
|
Well, technically it should probably be a major bump of base, since it does change the compilation target to es2017, and uses ts 3.5 now, and I've bumped the dependencies to services to just be 4.0rc0, instead of previous versions as well. HOWEVER, if all you were doing was importing the token so you could register a custom widget, likely no change needed. So it seems like a bit of unnecessary work to make 3rd party libraries release a new version just to have @jupyter-widgets/base 2.0. However, it does put us on better footing moving forward. Another alternative would be to try to shoehorn the changes in base to still support old versions of @jupyterlab/services and not upgrade the ts targets, etc. That would enable current widget libraries to keep working without updates. Thoughts? @SylvainCorlay? |
I would be fine with a major bump of
Nah, regardless that feels a bit overkill. |
The biggest ramification of this is that every third-party extension will need to bump and republish their js versions (and hence their python versions for classic extensions) since they all rely on base directly or indirectly, probably with semver range |
Do you have to bump major when bumping a dependency major version? |
|
I didn't say they would have to bump major, though that would be good practice if they are depended on. The key is that they will need to publish a new version. |
|
If we don't bump major, what do we know already depends on the content of |
|
Probably anyone depending on base for doing a new widget manager would break (like the examples in our repo broke, for instance). Possibly someone building a third-party extension that doesn't understand js classes (since we have a new ts target). Also someone using |
|
ok, so voila breaks. |
|
On the other hand, I think things like ipyvolume, pythreejs, bqplot, etc. probably would all work just fine and require no code changes beyond updating their dependencies (i.e., if we published base as a patch release, these libraries probably would work just fine) |
Probably. Perhaps that is also a good test case to see if it really does break. |
|
Regardless, I think it's important to have this PR in a published version of ipywidgets before the jlab release later this week. |
|
Having base change its compilation target from ES5 to ES2017 is definitely a breaking change that should require a major version bump. I don't see a safe way around it, given that we have a very limited overview of how people consume it (semver is the only real guarantee we give). |
Note that having services change its compilation target to es2017 may be enough for us to force the major bump here as well. |
lock
bot
added
the
resolved-locked
This also updates a number of packages, moves the tsconfig files up to the package root directories, and fixes numerous typescript errors.