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

Revise process of making bundles and simplify making partial bundles #5508

Merged
merged 15 commits into from Feb 22, 2021

Conversation

archmoj
Copy link
Contributor

@archmoj archmoj commented Feb 17, 2021

Resolves #5484.
Also resolves #4949.

Now one could simply use

npm run partial-bundle pie sunburst --name=custom

to have "browserified" partial bundles (both minified and unminified) in dist folder.
As displayed in the output of this program the temporary index file for such custom build would be created inside build folder not lib and would be labeled as index-custom.js.

Also to mention regarding this PR:

  • good portion of lib folder is now auto-generated
  • label traces, transforms and calendars files inside lib folder as "deprecated"
  • ensure following index.js registering order in all bundles
  • make separate scripts for extra and custom partial bundles
  • integrate header_dist task into bundle tasks
  • remove confusing dev flags from dist bundle

@plotly/plotly_js

 - simplify lib folder and generate index files for partial bundles in build
 - remove confusing dev flags from dist bundle
 - make a separate script for partial bundles
 - integrate header_dist into bundle tasks
@nicolaskruchten
Copy link
Member

I feel like removing all these files from lib will be very disruptive to folks who currently follow the instructions in the main readme about "modules"... Is it really problematic to keep them there? I agree they seem redundant but we've had this readme up there for so long that these files kind of feel like a part of the API at this point...

@alexcjohnson
Copy link
Contributor

That's a good point @nicolaskruchten - I suppose we could keep them around but not use them ourselves, and deprecate them so they can be removed in v3?

I guess perhaps the purpose of having this extra layer was to make it clear to folks where the entry points are for Plotly.register. But we never actually said that's what we were doing AFAICT and the pattern isn't that complicated, we can just document it: src/traces/<anything>, src/transforms/<anything>, and src/components/calendars. Would be interesting to see if we can take other stuff from components out of core and into the bundle index files but that's for another time.

@archmoj
Copy link
Contributor Author

archmoj commented Feb 17, 2021

Q1: In addition to traces, transforms, calendars components do we want to keep index-*.js related to partial bundles in lib?
Q2: Instead of files, can't we simply use soft link to point to traces, transforms, calendars components?

@archmoj
Copy link
Contributor Author

archmoj commented Feb 17, 2021

I still think that having those redundant lib files are more confusing than helpful for the users as well as contributors.

BTW here is an example script to generate a custom bundle including pie and sunburst:

npm run partial-bundle pie sunburst name=custom

It also generates and prints the index-custom.js which folks could easily find and use if one ever wants to require.

@nicolaskruchten
Copy link
Member

I agree they're confusing but I think we should keep them anyway, to reduce the number of breaking changes in 2.0.

@archmoj
Copy link
Contributor Author

archmoj commented Feb 17, 2021

I agree they're confusing but I think we should keep them anyway, to reduce the number of breaking changes in 2.0.

If we want to keep this folder around we should cleanup lib/* (similar to what we now do for dist) and generate those files automatically.

@nicolaskruchten
Copy link
Member

Why don't we just leave lib alone just for historical reasons? it's not really hurting anyone and we can leave a readme in there saying "here for historical reasons" and then change the main readme to point to the new location

@archmoj
Copy link
Contributor Author

archmoj commented Feb 17, 2021

Why don't we just leave lib alone just for historical reasons? it's not really hurting anyone and we can leave a readme in there saying "here for historical reasons" and then change the main readme to point to the new location

We shouldn't keep unused files as the API input. Here is one risk:
Everytime one submits a PR we have to check if they changed something in this historical lib.
But if the components listed in lib are created/update/maintained automatically I would be fine with it.

@nicolaskruchten
Copy link
Member

We can generate them if you feel strongly about it :)

@archmoj
Copy link
Contributor Author

archmoj commented Feb 19, 2021

We can generate them if you feel strongly about it :)

100%.
I could argue that we could regenerate those in a patch/minor after v2 if people really needed them.
So this PR is ready to review.

@nicolaskruchten
Copy link
Member

Ah I think we're misunderstanding each other: I really want these to not be removed in this PR, as this would constitute a new breaking change for people who have followed the instructions in our readme. If you want to generate these identical files moving forward that's fine with me.

@archmoj
Copy link
Contributor Author

archmoj commented Feb 19, 2021

Ah I think we're misunderstanding each other: I really want these to not be removed in this PR, as this would constitute a new breaking change for people who have followed the instructions in our readme. If you want to generate these identical files moving forward that's fine with me.

Are you referring to a README other than plotly.js/README.md?

@nicolaskruchten
Copy link
Member

Nope... the main readme contains this section https://github.com/plotly/plotly.js#modules

image

@archmoj
Copy link
Contributor Author

archmoj commented Feb 19, 2021

Related PR: #202

@archmoj
Copy link
Contributor Author

archmoj commented Feb 19, 2021

Also interesting to see here that users were actually looking for a partial-bundle script.

@nicolaskruchten
Copy link
Member

Yes, I agree that the current readme is not really all that helpful in that it doesn't show how to actually make a custom bundle, which is what this current PR is meant to do. But I also don't want to break things for folks who have followed these instructions that have been in our readme for a long time. Basically: these lib files are part of the documented, public API for 1.x and I don't want this removal to be part of the 2.x breakage please.

 - generated component files using preprocess in lib
 - deprecate component files in lib
… lib folder

 - generated index files for our partial bundles using extra-bundles script
@archmoj
Copy link
Contributor Author

archmoj commented Feb 22, 2021

Yes, I agree that the current readme is not really all that helpful in that it doesn't show how to actually make a custom bundle, which is what this current PR is meant to do. But I also don't want to break things for folks who have followed these instructions that have been in our readme for a long time. Basically: these lib files are part of the documented, public API for 1.x and I don't want this removal to be part of the 2.x breakage please.

Addressed in 01136b7 and aeaf709.

@archmoj archmoj requested review from alexcjohnson and removed request for alexcjohnson February 22, 2021 16:22
@archmoj archmoj changed the title Revise process of making bundles Revise process of making bundles and simplify making partial bundles Feb 22, 2021
lib/core.js Outdated
@@ -1,3 +0,0 @@
'use strict';

module.exports = require('../src/core');
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess we'd better bring this file back, as it was referenced in the readme

]);

module.exports = require('./register_extra')(Plotly);
module.exports = (function(Plotly) { return Plotly; })(core);
Copy link
Contributor

Choose a reason for hiding this comment

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

Personally it feels to me like this indirection makes things more confusing than the previous pattern - which with register_extra removed becomes just:

var Plotly = require('../src/core');

Plotly.register([...]);

module.exports = Plotly;

Is there another reason for it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

register_extra file is not documented and confusing.
Until we could bump d3 (cc: #5112) or possibly release a @plotly/d3-v3 patch to fix unexpected characters at build time we need a function to the return correct result.

require('./violin'),
require('./image'),
require('./pie'),

Copy link
Contributor Author

@archmoj archmoj Feb 22, 2021

Choose a reason for hiding this comment

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

As you can see, image and pie used to be registered in a different order in cartesian bundles.

require('./ohlc'),
require('./candlestick'),
require('./funnel'),
require('./waterfall'),
require('./indicator')
Copy link
Contributor Author

Choose a reason for hiding this comment

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

As you can see, funnel and waterfall and indicator used to be registered in a different order in finance bundles.

README.md Outdated
@@ -96,13 +96,9 @@ Then elsewhere in your code:
var Plotly = require('./path/to/custom-plotly');
```

#### Non-ascii characters
Alternatively you could browserify a custom bundle of desired trace modules e.g. `pie` and `choropleth` using
`npm run partial-bundle pie choropleth name=custom`
Copy link
Member

Choose a reason for hiding this comment

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

it would be nice if this followed the usual command-line flag patterns and hence had --name=custom instead of just name=custom IMO

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As a side note I don't want to rely on minimist; but OK I could look for --name when parsing the arguments.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done in 8d902aa.

Copy link
Contributor

@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.

💃 LGTM!

@archmoj archmoj merged commit d0ddf03 into master Feb 22, 2021
@archmoj archmoj deleted the improve-mk-bundles branch February 22, 2021 23:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

A new "npm run" target for building custom bundles Partial bundle for the treemap
3 participants