Jsdelivr: auto-minification issue with ionify

[iskitz]

The github auto-minification instructions

Add ".min" to any JS/CSS file to get a minified version - if one doesn't exist, we'll generate it for you. All generated files come with source maps and can be easily used during development:

https://cdn.jsdelivr.net/gh/jquery/[email protected]/src/core.min.js
Minifying a large file can take several seconds. However, we store all generated files in our permanent storage, so this delay only applies to the first few requests.

don't work with these javascript files

• https://cdn.jsdelivr.net/gh/ionify/ionify@public/web.min.js
• https://cdn.jsdelivr.net/gh/ionify/ionify@public/ions/on.ion.min.js

jsdelivr returns this essentially similar message with no content for both

/**

• Minified by jsDelivr using Terser v3.14.1.
• Original file: /gh/ionify/ionify@public/web.js
  *
• Do NOT use SRI with dynamically generated files! More information: https://www.jsdelivr.com/using-sri-with-dynamic-files
  */
  //# sourceMappingURL=/sm/88df9541de928e9d732efbd81ac4471116db80dcfc4c3e43e6c56fb97f5eeecd.map

The original files each load correctly from jsdelivr without the .min.js option and when combined via

https://cdn.jsdelivr.net/combine/gh/ionify/ionify@public/web.js,gh/ionify/ionify@public/ions/on.ion.js

[MartinKolarik]

When minifying files, it is generally expected that they are standalone and not meant to be concatenated or merged with other files before running them. I'm not sure how those files are supposed to be used but they do not do anything on their own so the minifier correctly removes everything as dead code.

[iskitz]

Hi @MartinKolarik,

Thanks for quickly replying.

Though the syntax of the code in the referenced Javascript files is novel, each of those files is valid standalone JavaScript that does specific things, and isn’t dependent on being concatenated or merged with any other file to run.

You can see the scripts being fetched & ran independently in any JavaScript-enabled web browser by viewing https://anemojii.glitch.me then using the browser’s developer tools to view the site’s network activity.

Since these are valid standalone JavaScript files with no dead code, minification should work correctly, and shouldn’t remove any of their code.

[MartinKolarik]

Ok, you are right, it relies on valueOf being called by preceding the object with ~, which is a valid but highly nonstandard pattern.

As the comment in our minified file says, we use Terser for minification, so I can only suggest checking if this happens with the latest version (jsDelivr is still on v3, latest is v4) and if yes, raising an issue in their repo. In case it doesn't happen with v4 then it'll be fixed at jsDelivr in the near future when we upgrade to the latest version.

[iskitz]

Yep, you got it, they use valueOf to derive meaning & behavior from object literals that've been activated by ~.

re: minification:

I looked into how Terser & its predecessor Uglify interact with ions: invoked object notations, the pattern used by the two scripts I've mentioned in this issue.

I found that setting Terser's compress option to false fixes the issue & produces minified code. Looking deeper I found that disabling Uglify's side_effects option also solved the problem & that Terser's similar config option did too:
js {compress: {side_effects: false}}
Since these config options exist & when used eliminate the problem, this seems less like a Terser bug & more like a jsDelivr auto-minification enhancement request.

This led me to these questions & thoughts about how to possibly address this:

• Can jsDelivr set Terser's side_effects compress config option to false?

  • this seems like a low effort, low disruption approach
  • would keep side-effect-free statements in outputted code
  • affects all repos using auto-minifcation

• Can jsDelivr set Terser's compress config option to false?

  • this seems like a low effort, but potentially high disruption (increased file size) approach
  • affects all repos using auto-minifcation

• Can jsDelivr enable & use author-defined minification rule config files like .terserrc similar to eslint's .eslintrc lint config?

  • this could be low effort, low disruption & high impact if repos already have .terserrc files
  • this would isolate custom minification behavior to individual repos
  • this would enable me to set compress options as needed for ionify
  • maybe jsDelivr can read it directly since I believe it uses the Terser API, e.g.
    js var options = JSON.parse (fs.readFileSync (".terserrc", "utf8")); Terser.minify (code, options);
  • Terser offers this CLI option --config-file <file> Read minify() options from JSON file.

[MartinKolarik]

Indeed, there's an assumption that valueOf() will have no side effects mentioned at https://github.com/terser/terser#compiler-assumptions. We'll check what difference the side_effects option makes.

[iskitz]

Sounds good @MartinKolarik. Please let me know what you find.

Here’re some additional observations I’ve made since our last chat:

The compress sequences option that defaults to true also causes significant portions of valid code to be omitted from minified output.

Setting the sequences and side_effects compress options to false corrects the problem:

{ compress:
    { sequences   : false,
      side_effects: false
    }
}

but setting sequences to false has an adverse effect of meaningfully increasing minified file size. That could have a significant negative effect on other repos and their users if applied globally to all repos.

This situation is a tangible justification for my earlier proposal to have jsDelivr use per-repo terser config rules via.terserrc files when present.

That would enable repos like ionify to effectively use jsDelivr’s auto-minification without negatively affecting other jsDelivr-served repos.

[MartinKolarik]

That's rather weird, based on what that option is for, I wouldn't expect it to make a difference in what code is dropped.

Regarding the author-defined config, I don't think this is something we could do in the near future.

First, it's a potential security problem and would need to be examined and implemented carefully.

Second, if a package contained the config file, it would almost always contain the minified files as well. The only exception would be if the author specifically relied on jsDelivr to generate the files but needed to change the config, as in your case. However, this is a very rare case and since author's involvement is needed anyway, they may just ship the minified files themselves. The main point of auto minification is that's it's zero config and you can use it even when the author doesn't want/care to ship the minified files.

I do think it makes sense to examine the compress option and if there's something that might improve compatibility without significantly affecting the size, we could change it. But in your case it might just make more sense to setup a GH action to automatically minify and publish the files to npm or another GH branch or repo.

[iskitz]

Great points re: security & the likelihood of files already being minified if their package contained a config file. I didn’t consider that and agree that it’s probably simpler to have ionify do its own minification so I’ll look into automating that via Github.

I was, and still am excited about jsDelivr’s zero-config on-demand & persistent file minification & combination. I find those features really convenient & helpful for performance, and now expect them from top-tier cdns.

I’m still concerned about Terser’s compression operation and think it’s important to confirm why the sequences compress option causes the code omission problem I’m seeing. I’ll look into that and file a Terser issue if it’s indeed a bug in their compression process.

[iskitz]

Following up:

I filed terser/terser#644 but it was closed due to terser’s pre-existing decision to not handle code affecting .valueOf(). Based on the conversation there, I don’t believe it’s useful for you (jsDelivr) to look further into terser’s compress config option as it relates to its effect on ionify.

I’m disappointed I won’t be able to use jsDelivr’s auto-minification functionality because it was one less task to do & handle as a package author who deeply values performance.

I was excited to see how much jsDelivr was doing with features like on-demand & persisted minification & combination to optimize file transfer between server & client. I see all such activities as reasonable, even if uncommon, for cdns to do to provide consistently maximal performance irrespective of package author effort. I love that jsDelivr is already using HTTP/2 and was excited to see how much shorter load time could be with the added compression.

Thanks again for the conversation & keep up the great work. I’m really happy that jsDelivr exists and that you all are continuing to do this innovative & great work.