minify | fingerprint does not work with an explicit new Date() #8954
Labels
Comments
|
I tested this with the tdewolff/minify online demo: Workaround: replace Underlying problems:
I'm not convinced that the first is actually a problem. |
|
Yes, at least we should see a warning. I didn't notice the problem at first and then pushed some changes to our staging environment. Turns out, on one of the pages, one javascript file didn't load anymore. Hugo still seems to include the file, but it is not minified. |
|
A simple failing test: This produces nothing, and should throw: |
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
Sep 4, 2021
Previously, *minifyTransformation.Transform suppressed the error returned by t.m.Minify. This meant that when minification returned an error, the error would not reach the user. Instead, minification would silently fail. For example, if a JavaScript file included a call to the Date constructor with: new Date(2020, 04, 02) The package that the minification library uses to parse JS files, github.com/tdewolff/parse would return an error, since "04" would be parsed as a legacy octal. However, the JS file would remain un-minified with no error. Fixing this is not as simple as replacing "_" with an "err" in *minifyTransformation.Transform, however (though this is necessary). If we only returned this error from Transform, then hugolib.TestResourceMinifyDisabled would fail. Instead of being a no-op, as TestResourceMinifyDisabled expects, using the "minify" template function with a "disableXML=true" config setting instead returns the error, "minifier does not exist for mimetype." The "minifier does not exist" error is returned because of the way minifiers.New works. If the user's config disables minification for a particular MIME type, minifiers.New does not add it to the resulting Client's *minify.M. However, this also means that when the "minify" template function is executed, a *resourceAdapter's transformations still add a minification. When it comes time to call the minify.Minifier for a specific MIME type via *M.MinifyMimetype, the github.com/tdewolff/minify library throws the "does not exist" error for the missing MIME type. The solution was to change minifiers.New so, instead of skipping a minifier for each disabled MIME type, it adds a NoOpMinifier, which simply copies the source to the destination without minification. This means that when the "minify" template function is used for a particular resource, and that resource's MIME type has minification disabled, minification is genuinely skipped, and does not result in an error. In order to add this, I've fixed a possibly unwanted interaction between minifiers.TestConfigureMinify and hugolib.TestResourceMinifyDisabled. The latter disables minification and expects minification to be a no-op. The former disables minification and expects it to result in an error. The only reason hugolib.TestResourceMinifyDisabled passes in the original code is that the "does not exist" error is suppressed. However, we shouldn't suppress minification errors, since they can leave users perplexed. I've changed the test assertion in minifiers.TestConfigureMinify to expect no errors and a no-op if minification is disabled for a particular MIME type. Resolves gohugoio#8954
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
Sep 11, 2021
Previously, *minifyTransformation.Transform suppressed the error returned by t.m.Minify. This meant that when minification returned an error, the error would not reach the user. Instead, minification would silently fail. For example, if a JavaScript file included a call to the Date constructor with: new Date(2020, 04, 02) The package that the minification library uses to parse JS files, github.com/tdewolff/parse would return an error, since "04" would be parsed as a legacy octal. However, the JS file would remain un-minified with no error. Fixing this is not as simple as replacing "_" with an "err" in *minifyTransformation.Transform, however (though this is necessary). If we only returned this error from Transform, then hugolib.TestResourceMinifyDisabled would fail. Instead of being a no-op, as TestResourceMinifyDisabled expects, using the "minify" template function with a "disableXML=true" config setting instead returns the error, "minifier does not exist for mimetype." The "minifier does not exist" error is returned because of the way minifiers.New works. If the user's config disables minification for a particular MIME type, minifiers.New does not add it to the resulting Client's *minify.M. However, this also means that when the "minify" template function is executed, a *resourceAdapter's transformations still add a minification. When it comes time to call the minify.Minifier for a specific MIME type via *M.MinifyMimetype, the github.com/tdewolff/minify library throws the "does not exist" error for the missing MIME type. The solution was to change minifiers.New so, instead of skipping a minifier for each disabled MIME type, it adds a NoOpMinifier, which simply copies the source to the destination without minification. This means that when the "minify" template function is used for a particular resource, and that resource's MIME type has minification disabled, minification is genuinely skipped, and does not result in an error. In order to add this, I've fixed a possibly unwanted interaction between minifiers.TestConfigureMinify and hugolib.TestResourceMinifyDisabled. The latter disables minification and expects minification to be a no-op. The former disables minification and expects it to result in an error. The only reason hugolib.TestResourceMinifyDisabled passes in the original code is that the "does not exist" error is suppressed. However, we shouldn't suppress minification errors, since they can leave users perplexed. I've changed the test assertion in minifiers.TestConfigureMinify to expect no errors and a no-op if minification is disabled for a particular MIME type. Resolves gohugoio#8954
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
Sep 14, 2021
Previously, *minifyTransformation.Transform suppressed the error returned by t.m.Minify. This meant that when minification returned an error, the error would not reach the user. Instead, minification would silently fail. For example, if a JavaScript file included a call to the Date constructor with: new Date(2020, 04, 02) The package that the minification library uses to parse JS files, github.com/tdewolff/parse would return an error, since "04" would be parsed as a legacy octal. However, the JS file would remain un-minified with no error. Fixing this is not as simple as replacing "_" with an "err" in *minifyTransformation.Transform, however (though this is necessary). If we only returned this error from Transform, then hugolib.TestResourceMinifyDisabled would fail. Instead of being a no-op, as TestResourceMinifyDisabled expects, using the "minify" template function with a "disableXML=true" config setting instead returns the error, "minifier does not exist for mimetype." The "minifier does not exist" error is returned because of the way minifiers.New works. If the user's config disables minification for a particular MIME type, minifiers.New does not add it to the resulting Client's *minify.M. However, this also means that when the "minify" template function is executed, a *resourceAdapter's transformations still add a minification. When it comes time to call the minify.Minifier for a specific MIME type via *M.MinifyMimetype, the github.com/tdewolff/minify library throws the "does not exist" error for the missing MIME type. The solution was to change minifiers.New so, instead of skipping a minifier for each disabled MIME type, it adds a NoOpMinifier, which simply copies the source to the destination without minification. This means that when the "minify" template function is used for a particular resource, and that resource's MIME type has minification disabled, minification is genuinely skipped, and does not result in an error. In order to add this, I've fixed a possibly unwanted interaction between minifiers.TestConfigureMinify and hugolib.TestResourceMinifyDisabled. The latter disables minification and expects minification to be a no-op. The former disables minification and expects it to result in an error. The only reason hugolib.TestResourceMinifyDisabled passes in the original code is that the "does not exist" error is suppressed. However, we shouldn't suppress minification errors, since they can leave users perplexed. I've changed the test assertion in minifiers.TestConfigureMinify to expect no errors and a no-op if minification is disabled for a particular MIME type. Resolves gohugoio#8954
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
Sep 19, 2021
Previously, *minifyTransformation.Transform suppressed the error returned by t.m.Minify. This meant that when minification returned an error, the error would not reach the user. Instead, minification would silently fail. For example, if a JavaScript file included a call to the Date constructor with: new Date(2020, 04, 02) The package that the minification library uses to parse JS files, github.com/tdewolff/parse would return an error, since "04" would be parsed as a legacy octal. However, the JS file would remain un-minified with no error. Fixing this is not as simple as replacing "_" with an "err" in *minifyTransformation.Transform, however (though this is necessary). If we only returned this error from Transform, then hugolib.TestResourceMinifyDisabled would fail. Instead of being a no-op, as TestResourceMinifyDisabled expects, using the "minify" template function with a "disableXML=true" config setting instead returns the error, "minifier does not exist for mimetype." The "minifier does not exist" error is returned because of the way minifiers.New works. If the user's config disables minification for a particular MIME type, minifiers.New does not add it to the resulting Client's *minify.M. However, this also means that when the "minify" template function is executed, a *resourceAdapter's transformations still add a minification. When it comes time to call the minify.Minifier for a specific MIME type via *M.MinifyMimetype, the github.com/tdewolff/minify library throws the "does not exist" error for the missing MIME type. The solution was to change minifiers.New so, instead of skipping a minifier for each disabled MIME type, it adds a NoOpMinifier, which simply copies the source to the destination without minification. This means that when the "minify" template function is used for a particular resource, and that resource's MIME type has minification disabled, minification is genuinely skipped, and does not result in an error. In order to add this, I've fixed a possibly unwanted interaction between minifiers.TestConfigureMinify and hugolib.TestResourceMinifyDisabled. The latter disables minification and expects minification to be a no-op. The former disables minification and expects it to result in an error. The only reason hugolib.TestResourceMinifyDisabled passes in the original code is that the "does not exist" error is suppressed. However, we shouldn't suppress minification errors, since they can leave users perplexed. I've changed the test assertion in minifiers.TestConfigureMinify to expect no errors and a no-op if minification is disabled for a particular MIME type. Resolves gohugoio#8954
bep
pushed a commit
that referenced
this issue
Sep 22, 2021
Previously, *minifyTransformation.Transform suppressed the error returned by t.m.Minify. This meant that when minification returned an error, the error would not reach the user. Instead, minification would silently fail. For example, if a JavaScript file included a call to the Date constructor with: new Date(2020, 04, 02) The package that the minification library uses to parse JS files, github.com/tdewolff/parse would return an error, since "04" would be parsed as a legacy octal. However, the JS file would remain un-minified with no error. Fixing this is not as simple as replacing "_" with an "err" in *minifyTransformation.Transform, however (though this is necessary). If we only returned this error from Transform, then hugolib.TestResourceMinifyDisabled would fail. Instead of being a no-op, as TestResourceMinifyDisabled expects, using the "minify" template function with a "disableXML=true" config setting instead returns the error, "minifier does not exist for mimetype." The "minifier does not exist" error is returned because of the way minifiers.New works. If the user's config disables minification for a particular MIME type, minifiers.New does not add it to the resulting Client's *minify.M. However, this also means that when the "minify" template function is executed, a *resourceAdapter's transformations still add a minification. When it comes time to call the minify.Minifier for a specific MIME type via *M.MinifyMimetype, the github.com/tdewolff/minify library throws the "does not exist" error for the missing MIME type. The solution was to change minifiers.New so, instead of skipping a minifier for each disabled MIME type, it adds a NoOpMinifier, which simply copies the source to the destination without minification. This means that when the "minify" template function is used for a particular resource, and that resource's MIME type has minification disabled, minification is genuinely skipped, and does not result in an error. In order to add this, I've fixed a possibly unwanted interaction between minifiers.TestConfigureMinify and hugolib.TestResourceMinifyDisabled. The latter disables minification and expects minification to be a no-op. The former disables minification and expects it to result in an error. The only reason hugolib.TestResourceMinifyDisabled passes in the original code is that the "does not exist" error is suppressed. However, we shouldn't suppress minification errors, since they can leave users perplexed. I've changed the test assertion in minifiers.TestConfigureMinify to expect no errors and a no-op if minification is disabled for a particular MIME type. Fixes #8954
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Hugo are you using (
hugo version)?The issue appears in Hugo 0.81.0 and higher versions up to the current 0.88.0. The bug is not in 0.80.0 or previous versions. I suspect the cause to be in 66beac9
Does this issue reproduce with the latest release?
Yes.
Issue
We have various Javascript files that we include in the layout with
One Javascript file contains an explicit date creation:
new Date(2002, 04, 11). This file does not get minified, and theintegrityattribute is wrong such that the file is not loaded by the browser.I isolated the problem to the following minimal Javascript file:
If this file gets included via
. | minify | fingerprint, the file is not minified in the output, and the integrity attribute is erroneous.If the explicit Date creation is removed or replaced by the equivalent
new Date(1021068000000), the problem goes away.The text was updated successfully, but these errors were encountered: