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

feat: abstract minify and use value for all modes #3965

Merged
merged 14 commits into from
Sep 30, 2018

Conversation

manniL
Copy link
Member

@manniL manniL commented Sep 25, 2018

Types of changes

  • New feature (non-breaking change which adds functionality)

Description

Currently, we use generate.minify for configuring the html-minifier in generate mode.
With this PR we can use build.minify for all modes to fine-tune the minifier.

The value of build.minify will fall back to the old values in the respective modes to avoid a breaking change.

Resolves #3961, resolves #3964

Checklist:

Copy link
Member

@clarkdo clarkdo left a comment

Choose a reason for hiding this comment

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

Another thought is that if build.minify has some confusion with build.optimization.minifier?
How about htmlMinify or some name else?

lib/common/options.js Outdated Show resolved Hide resolved
// Legacy workaround for obsolete options.generate.minify

if (typeof this.options.build.minify === 'undefined') {
this.options.build.minify = {
Copy link
Member

Choose a reason for hiding this comment

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

I think this can be default value of build.minify directly.

Copy link
Member Author

Choose a reason for hiding this comment

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

The problem is that we'd possibly introduce a breaking change because this value is not equal to minify: true or the resulting default values (which was the value for SSR/SPA layout minification).

Copy link
Member

Choose a reason for hiding this comment

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

I think there actually no difference to users because they don’t need change anything and also wont influence their project features, it’s just some specific options of minifier, let’s ask @pi0 and @Atinux opinion.

Copy link
Member Author

Choose a reason for hiding this comment

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

In the past things like script injection broke because of minification (where closing tags were removed), so I can't judge which problems the changed setting might cause. 🙈

But it shouldn't be up to me ☺️

Copy link
Member

Choose a reason for hiding this comment

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

Yep, but current default options are more conservative than true, right? It should only fix sth instead of breaking 😅

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah! No, they are not. In this situation I completely agree!

@@ -47,13 +47,19 @@ export default class WebpackClientConfig extends WebpackBaseConfig {
plugins() {
const plugins = super.plugins()

// Legacy workaround for obsolete options.generate.minify

if (typeof this.options.build.minify === 'undefined') {
Copy link
Member

Choose a reason for hiding this comment

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

If we make above value as deault value, this part can be removed

@manniL
Copy link
Member Author

manniL commented Sep 25, 2018

I agree on changing the name to htmlMinify! That fits better and doesn't cause as much confusion

Copy link

@galvez galvez left a comment

Choose a reason for hiding this comment

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

@manniL just need to fix the unit test, otherwise LGTM

pi0
pi0 previously requested changes Sep 25, 2018
lib/common/options.js Outdated Show resolved Hide resolved
lib/builder/generator.js Outdated Show resolved Hide resolved
lib/builder/generator.js Outdated Show resolved Hide resolved
lib/builder/webpack/client.js Outdated Show resolved Hide resolved
@codecov-io
Copy link

codecov-io commented Sep 25, 2018

Codecov Report

Merging #3965 into dev will decrease coverage by 0.15%.
The diff coverage is 66.66%.

Impacted file tree graph

@@            Coverage Diff             @@
##              dev    #3965      +/-   ##
==========================================
- Coverage   97.56%   97.41%   -0.16%     
==========================================
  Files          18       18              
  Lines        1233     1237       +4     
  Branches      337      338       +1     
==========================================
+ Hits         1203     1205       +2     
- Misses         29       31       +2     
  Partials        1        1
Impacted Files Coverage Δ
lib/builder/webpack/client.js 96.87% <ø> (ø) ⬆️
lib/common/nuxt.config.js 100% <ø> (ø) ⬆️
lib/builder/generator.js 91.34% <66.66%> (-1.66%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0c1d94a...23cc12e. Read the comment docs.

@manniL
Copy link
Member Author

manniL commented Sep 25, 2018

I'll move all options-related stuff to options.js and will report back then.

@manniL
Copy link
Member Author

manniL commented Sep 25, 2018

Refactored the changes to use the former generate.minify as default value for build.htmlMinify and added a warning concerning overrides

@@ -209,6 +209,14 @@ Options.from = function (_options) {
delete options.render.gzip
}

// Legacy: Override build.htmlMinify with generate.minify if present
if (this.options.generate.minify) {
this.options.build.htmlMinify = this.options.generate.minify
Copy link
Member

Choose a reason for hiding this comment

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

This part still have the issue we just discussed, I think it should only be executed in generation

Copy link
Member Author

Choose a reason for hiding this comment

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

But how can we distinguish between generated and "normal" SSR?

Copy link
Member

Choose a reason for hiding this comment

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

Unfortunately we can’t, so maybe just warning default value willl be applied but not override build options? @pi0 How do you think?

Copy link
Member

Choose a reason for hiding this comment

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

That would be a SOFT BREAKING CHANGE :D Breaking change but warn to fix it :D But i agree.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's why I was unsure if we should really proceed this way. Also because can't oversee how much damage the new "defaults" can cause for SSR HTML minification 🤔

@manniL
Copy link
Member Author

manniL commented Sep 25, 2018

To avoid breaking changes, the minification settings will be overridden in the generator module when generate.minify is present (but not in options).

We can then introduce the minification improvements that are set as default values of build.htmlMinify in 2.1 without risking a breaking change.

if (this.options.generate.minify) {
minificationOption = this.options.generate.minify
consola.warn('generate.minify has been deprecated. Use build.htmlMinify instead!')
Copy link
Member

Choose a reason for hiding this comment

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

If we all agree to do this way, I suggest adding a message that this option will be removed in 2.1

Copy link
Member Author

Choose a reason for hiding this comment

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

You mean generate.minify? Though it's not super clean, I wouldn't remove the override in the next minor version. Otherwise, we don't follow semver.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, what I mean is just making warning message more clear

Copy link
Member Author

Choose a reason for hiding this comment

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

Would ...deprecated and will be removed in the next major version be sufficient?

Copy link
Member

Choose a reason for hiding this comment

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

Yep, good

@manniL
Copy link
Member Author

manniL commented Sep 25, 2018

I have no clue why the CI fails. Will investigate later on.
If anybody has an idea or so, feel free!

Update: I have a slight feeling that the old generator.minify settings will not work for SSR/SPA. 🤔

Update 2: My feeling was right 🙈

@manniL manniL requested review from pi0 and clarkdo September 26, 2018 20:58
@manniL
Copy link
Member Author

manniL commented Sep 27, 2018

I had to remove sortAttributes from the list of defaults because it broke the normal templates.
I'm confused though: Does minification happen before or after injecting the template (or both)? I've tried to trace it down and saw replacing the template happening quite early. Unfortunately hadn't time to dig in deeper.

Copy link
Member

@Atinux Atinux left a comment

Choose a reason for hiding this comment

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

Good for me, could you add a PR to nuxt/docs?

@manniL
Copy link
Member Author

manniL commented Sep 28, 2018

Will add a doc PR, yup!

@manniL
Copy link
Member Author

manniL commented Sep 28, 2018

@Atinux PR added and linked.

@Atinux Atinux merged commit d69b4b8 into dev Sep 30, 2018
@Atinux Atinux deleted the feat-abstract-html-minifier branch September 30, 2018 16:13
@lock
Copy link

lock bot commented Oct 31, 2018

This thread 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 Oct 31, 2018
@danielroe danielroe added the 2.x label Jan 18, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
8 participants