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

Reduce stats requested at emit and optionally remove from template #825

Closed

Conversation

niftymonkey
Copy link

@niftymonkey niftymonkey commented Dec 13, 2017

At Trello we have been dealing with some build speed issues related to building multiple locale specific HTML files. These issues are similar to what's described here.

After instrumenting this plugin, I found that the majority of the time spent here is in the two toJson calls that are done. This change modifies the stats we request in the initial toJson call in the emit callback and also provides a constructor property that allows plugin users to opt out of the toJson call that is done in the template handler. In our case, we didn't need access to that webpack variable in our template, and therefore did not need the overhead of the toJson call.

@niftymonkey niftymonkey changed the title Reduce stats requested at emit and provide hook to avoid toJson call … [WIP] Reduce stats requested at emit and optionally remove from template Dec 13, 2017
@niftymonkey niftymonkey changed the title [WIP] Reduce stats requested at emit and optionally remove from template Reduce stats requested at emit and optionally remove from template Dec 13, 2017
@gerges-zz
Copy link

For the Trello team, these changes reduced the HML generation step of our build from 20+ seconds to 3. We'd love to see these changes merged upstream.

@gregjacobs
Copy link

Hey @niftymonkey, instead of a constructor property to prevent the .toJson() call for the template, could you instead make the webpack property into a getter that lazily calls stats.toJson()?

Then the performance hit is only for people using the webpack property, without the extra plugin option to worry about

@gerges-zz
Copy link

@gregjacobs the issue with attempting to make this property lazy has to do with how the internal template loader works. Take a look at this line: https://github.com/jantimon/html-webpack-plugin/blob/master/lib/loader.js#L46

That line of code writes out function scoped vars to make accessing template params not require another call. Part of the code it generates will include var webpack = templateParams.webpack;, which is going to call a get accessor defined on templateParams, 'webpack'. You could rewrite that code to in turn define all those properties as lazy as well on global, but things start to get ugly.

Would love some direction from maintainers on the route they'd like to go. Is this actively maintained @jantimon / @mastilver ?

@gregjacobs
Copy link

gregjacobs commented Dec 22, 2017

@gerges Oh ugh.. Didn't realize it was implemented that way.

One way to get around that might be to just surround the template code in a with statement:

'module.exports = function (templateParams) {' +
    'with(templateParams) {' +
        // Execute the lodash template
        'return (' + template.source + ')();' +
    '}' +
'}';

Although the with keyword is no longer allowed in strict mode, so that would only run if the rest of the code wasn't running under strict mode.

Might be best to have a plugin option after all

EDIT: Never mind on the with statement. Apparently that was the first attempt in the codebase anyway, but there is a comment in that source file that says that Webpack 2 doesn't allow the with statement, and hence the workaround of writing out the variables individually

@gregjacobs
Copy link

Or another option would be an AST transform of the template source to prepend templateParams. to each identifier which corresponds to a key in the templateParams object.

Maybe more effort than it's worth..

@niftymonkey
Copy link
Author

@gregjacobs Yeah, that's kinda where we landed. Anything past this did seem a little more effort than it was worth to to solve the problem initially. Again though, as @gerges mentioned, if there's anything the maintainers need to have done before we can get this merged, I'd be happy to oblige.

cc: @jantimon @ampedandwired

@gregjacobs
Copy link

@jantimon, @mastilver please merge this PR

@niftymonkey
Copy link
Author

Any chance for a merge on this one @jantimon ?

@jantimon
Copy link
Owner

What about the following solution:

#830 (comment)

It would allow us to remove it from the template but also allow users who really need it to add it back in

@jantimon
Copy link
Owner

l’ll close this issue for now - please let me know if the proposed solution might not work.

@jantimon jantimon closed this Mar 21, 2018
@jantimon
Copy link
Owner

Implemented in 3.1.0.

Please try templateParameters: false to overwrite the template variables entirely

source: false,
timings: false,
version: false
};
Copy link

@n0v1 n0v1 May 25, 2018

Choose a reason for hiding this comment

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

I think this could be simplified according to the docs:

var chunkOnlyConfig = {
  all: false,
  chunks: true
};

Copy link
Owner

Choose a reason for hiding this comment

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

Cool good point! 👍
We will remove the getStats call in #953

Copy link

Choose a reason for hiding this comment

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

Even better 👍. Thanks for your work!

@lock
Copy link

lock bot commented Jun 25, 2018

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jun 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants