Es5 target

[SylvainCorlay]

Summary

For custom widget authors:

The end result of this PR is that in order for a custom widget to work in JupyterLab 1.0, it must require @jupyter-widgets/base version 2. To work in the classic notebook or JupyterLab 0.35, it should require @jupyter-widgets/base version 1. We suggest that a custom widget be updated to depend on @jupyter-widgets/base version ^1 || ^2 in order to work in both the classic notebook, JupyterLab 0.35, and JupyterLab 1.0.

[SylvainCorlay]

cc @vidartf

[jasongrout]

Can we just switch the base package and maybe controls and output to es5? I don't think there's any reason to switch the jlab manager to es5.

[jasongrout]

(you can switch just those packages to es5 by putting those two lines in their tsconfigs, which would override the base config they are inheriting from)

[SylvainCorlay]

The individual tsconfig files don't seem to be actually taken into account.

Maybe it has to do with the removal of the --project option to tsc.

[SylvainCorlay]

Seems to work. Pushing soon (when wifi improves on Eurostar).

[jasongrout]

what about this (on top of 01c1536 from this PR)

diff --git a/packages/base/test/tsconfig.json b/packages/base/test/tsconfig.json
index 5fbcff44..186097c0 100644
--- a/packages/base/test/tsconfig.json
+++ b/packages/base/test/tsconfig.json
@@ -1,9 +1,11 @@
 {
   "extends": "../../../tsconfigbase",
   "compilerOptions": {
-    "types": ["mocha"],
+    "lib": ["dom", "es5", "es2015.promise", "es2015.iterable"],
     "outDir": "build",
-    "rootDir": "src"
+    "rootDir": "src",
+    "target": "es5",
+    "types": ["mocha"]
   },
   "include": ["src/*"]
 }
diff --git a/packages/base/tsconfig.json b/packages/base/tsconfig.json
index a1e4ba13..cf27bd24 100644
--- a/packages/base/tsconfig.json
+++ b/packages/base/tsconfig.json
@@ -1,8 +1,10 @@
 {
   "extends": "../../tsconfigbase",
   "compilerOptions": {
+    "lib": ["dom", "es5", "es2015.promise", "es2015.iterable"],
     "outDir": "lib",
-    "rootDir": "src"
+    "rootDir": "src",
+    "target": "es5",
   },
   "include": ["src/*"]
 }
diff --git a/packages/controls/test/tsconfig.json b/packages/controls/test/tsconfig.json
index 21efb391..5e891665 100644
--- a/packages/controls/test/tsconfig.json
+++ b/packages/controls/test/tsconfig.json
@@ -1,9 +1,11 @@
 {
   "extends": "../../../tsconfigbase",
   "compilerOptions": {
-    "types": ["mocha"],
+    "lib": ["dom", "es5", "es2015.promise", "es2015.iterable"],
     "outDir": "build",
-    "rootDir": "src"
+    "rootDir": "src",
+    "target": "es5",
+    "types": ["mocha"]
   },
   "include": ["src/**/*"]
 }
diff --git a/packages/controls/tsconfig.json b/packages/controls/tsconfig.json
index b566925b..31060f20 100644
--- a/packages/controls/tsconfig.json
+++ b/packages/controls/tsconfig.json
@@ -1,8 +1,10 @@
 {
   "extends": "../../tsconfigbase",
   "compilerOptions": {
+    "lib": ["dom", "es5", "es2015.promise", "es2015.iterable"],
     "outDir": "lib",
     "rootDir": "src",
+    "target": "es5",
     "types": ["mathjax", "node"]
   },
   "include": ["src/**/*"],
diff --git a/tsconfigbase.json b/tsconfigbase.json
index 1c79db37..6e815981 100644
--- a/tsconfigbase.json
+++ b/tsconfigbase.json
@@ -5,7 +5,6 @@
     "declaration": true,
     "esModuleInterop": true,
     "incremental": true,
-    "lib": ["dom", "es5", "es2015.promise", "es2015.iterable"],
     "jsx": "react",
     "module": "esnext",
     "moduleResolution": "node",
@@ -14,7 +13,7 @@
     "noUnusedLocals": true,
     "preserveWatchOutput": true,
     "resolveJsonModule": true,
-    "target": "es5",
+    "target": "es2017",
     "types": []
   }
 }

[SylvainCorlay]

Actually, not, it does not seem that we can change the target by overriding the target in individual tsconfig.json. It is not taken into account at all.

[jasongrout]

Actually, not, it does not seem that we can change the target by overriding the target in individual tsconfig.json. It is not taken into account at all.

It seems to work for me. Did you completely clean things out and reinstall the npm packages?

[SylvainCorlay]

It builds but produces es2017. Need to check with a complete git clean. Was trying to avoid it because of the slow wifi on the eurostar.

…

On Mon, Jul 1, 2019, 10:36 Jason Grout ***@***.***> wrote: Actually, not, it does not seem that we can change the target by overriding the target in individual tsconfig.json. It is not taken into account at all. It seems to work for me. Did you completely clean things out and reinstall the npm packages? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2472?email_source=notifications&email_token=AASJOFWYTN7VHVNFMO3VTCTP5HF2TA5CNFSM4H4P2UJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY5SIMA#issuecomment-507192368>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASJOFXV67NTUF4ROOF32NTP5HF2TANCNFSM4H4P2UJA> .

[jasongrout]

I'm fine with either the PR as it stands, or (preferable to me) bumping to es2017 for everything except base and controls, as in my patch above.

I still think this involves a major version bump in base, but I think most widget libraries would be able to just add the major version as an 'or' in their semver dependencies, i.e., bqplot probably could release a new patch version with:

"@jupyter-widgets/base": "^1.0.0 || ^2.0.0",

as its dependency (and perhaps update the controls dev dependency as well?)

[jasongrout]

It builds but produces es2017.

It definitely produces es5 for me. Perhaps just deleting the incremental compilation caches is enough to redo the build?

[maartenbreddels]

Note that you need to rm tsconfig.tsbuildinfo very often, tsc keeps a hash of the sources, and will not re-output if you change the output target.

[jasongrout]

Perhaps just deleting the incremental compilation caches is enough to redo the build?

yarn run clean should delete these.

[SylvainCorlay]

yarn run clean should delete these.

Still no luck. Trying by deleting things manually.

[vidartf]

I still think this involves a major version bump in base

I'm confused about this. I thought the compile target bump was the only argument for bumping base?

[SylvainCorlay]

Still no luck. Trying by deleting things manually.

I got it to work by actually nuking my conda environment and re-installing everything. 😖

[SylvainCorlay]

Yeah! Test are passing and third-party widgets work.

[jasongrout]

I'm confused about this. I thought the compile target bump was the only argument for bumping base?

The services dependency went from:

    "@jupyterlab/services": "^1.0.1 || ^2.0.0 || ^3.0.0",

to

    "@jupyterlab/services": "^4.0.0",

Since we use and re-export typings from @jupyterlab/services, having a major version bump there means we need a major version bump.

Part of the problem is that the base package has too many things. We need the major version bump for the manager, but not for 3rd party widgets. Unfortunately, that means that 3rd party widgets need to bump (or at least add a dependency version) if the manager changes too much.

Alternatively, we could just declare that the base package is really on honoring semver for third party widgets.

[vidartf]

To sum up a longer discussion on gitter:

• The API of the base JS package changed enough to warrant a major bump, mainly because we are re-exporting types from @jupyterlab/services.
• If we want to claim that the Python packages follow semver, then we would strictly need to do a major bump of those as well.
• The typings that changed are only on lesser used parts of the API, so there is an argument that while we should be strict with the JS package semver, we are probably OK breaking semver for the Python package, and only do a minor release.

[vidartf]

Personally, my vote would be on doing major release of the Python package, but not try to rush in all other feature-requests / refactoring that is currently waiting for a major release. Rather, those would be punted to version 9. Most users do not actually have semver ranges for their Python dependencies, so a major bump shouldn't have to be a big thing. Only the very nervous puts ranging on python packages, and I think it would be nice of us to give them a fighting chance.

[jasongrout]

Link to even longer gitter discussion that I think is more nuanced than the summary above: https://gitter.im/jupyter-widgets/Lobby?at=5d1a11088dff05627ba70136

[jasongrout]

I'm in favor of:

1. ipywidgets 7.5, not 8.0 (this is a js thing, not a python thing)
2. major version bump to base (so 2.0)
3. probably minor bump to controls, with controls depending on base ^1 || ^2 - that is if there weren't other backwards incompatible changes besides the base upgrade
4. tell third party widget authors that their widgets should work fine in classic and jlab 0.35, but to get their widgets to work in jlab 1.0, they'll need to issue a patch release where they bump their js dependency from base ^1 to base ^1 || ^2.

[jasongrout]

I think moving forward we can:

• break base into base-widget and base-manager
• make a restricted interface for the manager exposed on a widget that lives in base-widget
• version base-widget and base-manager separately
• not sure where to put the jlab registry token- probably base-widget since that is the only thing we want people to depend on

Then base-manager depends on base-widget, and third-party libraries depend on base-widget, and we have two version numbers to communicate to two separate groups of people.

And @vidartf points out that we probably want to bump the compilation target to es2017 as well.

I think this would be an excellent change for 8.0 (it is a js-only thing, so we could probably do it before 8.0 if we weren't bumping the compilation target)

[jasongrout]

We could probably even leave the base-widget package just called base, and separate out the manager. That would make @jupyter-widgets/base 3.0, and base-manager depend on base 3.0. That would ease upgrading (custom widget authors would just need to update to ^1 || ^2 || ^3)

[SylvainCorlay]

That sounds like a good plan.

[cornhundred]

I tried setting jupyter-widgets/base to

"@jupyter-widgets/base": "^2",

in my package.json for my Clustergrammer2 widget in an attempt to get my widget to work on JLab 1.0. Now my widget works in the classic notebook on MyBinder and on my local machine on JLab 1.1.4, however it does not work JLab on MyBinder 0.34 (see https://github.com/ismms-himc/clustergrammer2-test/tree/cgm-0.5.5 for MyBinder links).

Is this expected behavior? @jasongrout recommended setting the jupyter-widgets/base requirement to either 1.1.10 or 2 (see jupyterlab/jupyterlab#7063 (comment)) prevented my widget from working on JLab 0.34 (MyBinder) or 1.1.4 (local machine).

[FlorianWetschoreck]

First of all, thank you for the fix with the @jupyter-widgets/base version ^1 || ^2. This works for me and we will use this insight to repair the currently broken qgrid extension. The currently proposed qgrid fix only works in Jupyter Lab and not both in Notebook and Lab. But this issue here made it work again on both platforms.

However, I am a little bit confused about the fix. Can you maybe give a little bit more insight why this works?

My guess is something along the following lines:
The Jupyter Notebook or Lab have their own versions of @jupyter-widgets/base bundled in their respective JS.
The custom extension does not actually bundle its own version of @jupyter-widgets/base during the build step but it expects the dependencies to be available at runtime. This is due to the webpack config which labels the @jupyter-widgets/base as external as can be seen here in the cookiecutter:
https://github.com/jupyter-widgets/widget-cookiecutter/blob/master/%7B%7Bcookiecutter.github_project_name%7D%7D/js/webpack.config.js

The only thing that the custom extension does at runtime is to check if the dependencies according to the package.json are available. And if so, then its fine? Or does it check this at all?

And since notebook and lab come with different versions of @jupyter-widgets/base everything works and this explains why either ^1 or ^2 must be available.