Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Disable inline sourcemaps on dev builds #6804

Closed
quigleyj-mavenomics opened this issue Jul 11, 2019 · 6 comments
Closed

Feature request: Disable inline sourcemaps on dev builds #6804

quigleyj-mavenomics opened this issue Jul 11, 2019 · 6 comments
Labels
enhancement status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. tag:Build System
Milestone

Comments

@quigleyj-mavenomics
Copy link

Recently I ran into an issue with lab builds where, due to large chunks of data being included in the build, the size of the sourcemaps ballooned to 40mb. This would not normally be more than a extension developer annoyance, but with inline sourcemaps the main JS build size grew to 72mb.

#6700 introduced this behavior with devtool: inline-source-map on by default in dev builds, which are currently the default for jupyter lab build.

Having a way to switch back to adjacent sourcemaps (either by default or by a flag) would alleviate this. Having it default back to adjacent sourcemaps would be my preference to minimize impact on end-users, though.

As a workaround, other people running into this can edit $prefix/lib/site-packages/jupyterlab/staging/webpack.config.js:

-    devtool: 'inline-source-map',
+    devtool: 'source-map',

This will hold until the next time the Jupyterlab python package is updated.

cf. https://gitter.im/jupyterlab/jupyterlab?at=5d2669a8cdb70805c97350a7

@telamonian
Copy link
Member

On the surface, it looks like the best solution to the problem would be for jupyter lab build to default to a production build.

@ian-r-rose @blink1073 For an end user (eg someone who install jlab using pip install jupyterlab), when exactly is jupyter lab build used? During the initial setup/install? When they install an extension?

In any case, the difference between a dev build and a production build is currently pretty slight. It's just the contents of jupyterlab/staging/webpack.prod.config.js, right? Is there any reason we shouldn't default to production for jupyter lab build?

@saulshanabrook
Copy link
Member

@telamonian Could we just switch the dev build to also use source-map instead of inline-source-map?

@telamonian
Copy link
Member

telamonian commented Jul 16, 2019

Could we just switch the dev build to also use source-map instead of inline-source-map?

Definitely also an option. Based on the info here, the advantages of inline are:

  • Better performance when debugging
  • Makes remote debugging easy

so probably nothing critical. Still, my preference would be that we figure out how to appropriately differentiate jupyter lab build from any actual dev build. In addition to devtool: 'source-map', there's likely a bunch of other optimizations that we could be making right now but aren't.

telamonian pushed a commit to telamonian/jupyterlab that referenced this issue Jul 23, 2019
Now that the production build is fixed, I think it's better to default to it. Indeed, we want users installing JupyterLab to have the best experience using the interface and it means running the optimized production build.

This is especially true for extensions built with React because in dev mode, they will use the React's development bundle which is known to be much slower than the production one.

See also: jupyterlab#6804 (comment)
telamonian pushed a commit to telamonian/jupyterlab that referenced this issue Jul 26, 2019
Now that the production build is fixed, I think it's better to default to it. Indeed, we want users installing JupyterLab to have the best experience using the interface and it means running the optimized production build.

This is especially true for extensions built with React because in dev mode, they will use the React's development bundle which is known to be much slower than the production one.

See also: jupyterlab#6804 (comment)
telamonian pushed a commit to telamonian/jupyterlab that referenced this issue Jul 31, 2019
Now that the production build is fixed, I think it's better to default to it. Indeed, we want users installing JupyterLab to have the best experience using the interface and it means running the optimized production build.

This is especially true for extensions built with React because in dev mode, they will use the React's development bundle which is known to be much slower than the production one.

See also: jupyterlab#6804 (comment)
@jasongrout
Copy link
Contributor

Is this fixed in #6907?

@telamonian
Copy link
Member

@jasongrout It should be fixed, but the changes from #6907 haven't been included in a release yet. So I guess once 1.1.0 has been published, then we can say this is fixed.

@jasongrout
Copy link
Contributor

Our procedure is that once it is merged into master, the issue is fixed and closed. I commented separately on #6907 to see if we should open another PR to backport to 1.0.x.

@lock lock bot added the status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label Sep 14, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Sep 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. tag:Build System
Projects
None yet
Development

No branches or pull requests

4 participants