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

Switch from browserify to webpack in order to be able to use most recent ES modules & allow JavaScript syntax beyond ES5 #6355

Merged
merged 27 commits into from
Dec 22, 2022

Conversation

archmoj
Copy link
Contributor

@archmoj archmoj commented Nov 1, 2022

@plotly/plotly_js

TODOs:

  • rewrite regl_codegen/devtools.js similar to test_dashboard/devtools.js.
  • fix glslify transform for regl based traces
  • rebuild stackgl_modules using webpack
  • do we still need to keep strict_d3.js? Possibly no!
  • remove watchified_bundle.js.
  • figure out function constructor issue then revert 834d411.
  • figure out few scattergl test failures in webgl-jasmine container
  • update readme files
  • try custom bundle scripts
  • do not generate separate .LICENSE.txt files
  • run compress_attributes transform when when creating bundles other than plotly-with-meta.js
  • do not minify plotly-with-meta.js

@alexcjohnson
Copy link
Collaborator

@archmoj this is looking great! My biggest comment so far: can we use webpack.config.js as an input to test_dashboard/server.js and karma.conf.js - and just modify what we need to for those two contexts? This would be easier to maintain, clearer about what's different between the three, and give more confidence that what works in one context works in all.

}
},
plugins: [
new NodePolyfillPlugin({ includeAliases: ['process'] })
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you figure out what this is needed for? Is it something in our code or in a dependency?

Comment on lines 40 to 42
'stream': require.resolve('stream-browserify'),
'buffer': require.resolve('buffer/'),
'assert': require.resolve('assert/')
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These too - where are these needed? (It's OK if they are needed, I'm mostly just curious, also relevant for anyone who might include plotly.js from source, not dist bundles)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call. assert and buffer are no longer needed. Addressed in 9fc5987.

@archmoj
Copy link
Contributor Author

archmoj commented Nov 3, 2022

TODO:

  • fix glslify transform for regl based traces

See https://github.com/chasevida/glslify-webpack.

watch: !argv.nowatch,
debug: true
webpack: {
target: ['web', 'es5'],

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still want to continuing support es5 syntax in our output.
But now the input syntax i.e. plotly.js source files as well as node_modules could be in es6 and further.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@archmoj FWIW we just dropped IE support in Dash - and we did it in a minor https://github.com/plotly/dash/releases/tag/v2.7.0

I'd be comfortable doing the same in plotly.js, but open to discussing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opened #6366.
Let's investigate it & decide on that separately.

@archmoj
Copy link
Contributor Author

archmoj commented Nov 11, 2022

@archmoj this is looking great! My biggest comment so far: can we use webpack.config.js as an input to test_dashboard/server.js and karma.conf.js - and just modify what we need to for those two contexts? This would be easier to maintain, clearer about what's different between the three, and give more confidence that what works in one context works in all.

The main part of config is reused now.

@archmoj
Copy link
Contributor Author

archmoj commented Nov 11, 2022

Bundle sizes are slightly reduced and are looking good to my eyes.

webpack-bundle-sizes-diff

var makeWatchifiedBundle = require('../../tasks/util/watchified_bundle');
var shortcutPaths = require('../../tasks/util/shortcut_paths');
var config = require('../../webpack.config.js');
config.optimization = { minimize: false };
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally even the test build would be minified, to give us further confidence we're testing the behavior of the real bundle, plus a sourcemap. Right now with no sourcemap all I see in the test dashboard is the single huge unminified bundle - all the code is there unmodified but it'd be a pain to connect it back to the source files during debugging.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The debugging is addressed in 458921f.
Now using development mode, the bundle content is different from production mode; but it builds & rebuilds faster.
This should be good for now. And we could further improve this configuration.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That'll work - what you see in the debugger isn't quite the same as the source files - it's been reformatted a bit and the require statements are transformed - but it's pretty close and easy to move from one to another 😄

Copy link
Collaborator

@alexcjohnson alexcjohnson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💃 Let's do it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants