Include minified version of the es6 module

[backspaces]

Could you include a minified version of dat.gui.module.js in the distribution? I realize dat.gui.module.min.js may be a long name but it would be a nice addition.

There may be an issue with minifiers and es6 format. I use https://github.com/Rich-Harris/butternut's squash command.

[GoToLoop]

I realize "dat.gui.module.min.js" may be a long name but it would be a nice addition.

How about "dat.gui.min.mjs", using the future ".mjs" extension? :P
http://2ality.com/2017/05/es-module-specifiers.html#why-new-extension

[donmccurdy]

I'm not sure I understand the value of adding a minified ES module to the distribution... the large majority of developers using ES modules are doing so within some build system that typically starts with un-minified source, then compiles away the import statements before minifying. This ensures backward compatibility with IE11, for example.

There may be an issue with minifiers and es6 format.

Could you explain the use case and issue further? You're trying to minify while keeping the file as an ES import, then importing it how? I guess I'm skeptical of the idea that just because minifying ES modules is error-prone, libraries should ship a pre-minified ES module in addition to all the other output targets by default... it seems like this is a tooling issue that minifiers should solve. But perhaps I've missed something. :)

How about "dat.gui.min.mjs", using the future ".mjs" extension?

If the .mjs extension becomes the standard I'm open to this, but I don't see it widely yet and as that article mentions, "support for .mjs [in] tools is ongoing". There hasn't been much new feature development on this library recently, just bug fixes, and I'm hesitant to try a newer distribution method that may break current users.

[backspaces]

I'm not sure I understand the value of adding a minified ES module to the distribution... the large majority of developers using ES modules are doing so within some build system that typically starts with un-minified source, then compiles away the import statements before minifying. This ensures backward compatibility with IE11, for example.

TL;DR
I hear you! Ever since es6, complicated builds have grown like crazy. I do believe, however, as the browsers and node become more modern, these build systems may not always be needed.

But it can't hurt to provide dat.gui.module.min.js for those of us who could use it.

Details:
In my case, I'm not using Rollup, for example, to make a single bundle for my entire simulation repo. This is because there are optional capabilities in the repo that may not be needed for all users. For example, the users may want to use my dat.gui module for UI, or they may embed my module in their own framework like React. Indeed, this is being done by the team I work with.

This is also true for other modules. So the core of the repo is indeed a rollup es6 module, while the optional features (UI, plotting, data convolution etc) are offered as single modules.

This is a team decision in which we refactor the model from the view. Thus the model is a rollup, and the the view can be part of a framework like React or a separate bundle/app of its own. We did this to promote separate modules/rollups for our large apps.

Also, I do not use a task manager like webpack, gulp etc. I simply use npm run scripts. I do use Rollup, but not until the production steps and as a simple command line tool. This allows write & run development

And, yes, any bundle comes both as a single rollup, and as a minified rollup. For small repos like yours and mine, it is questionable as to whether or not minifying is a win. But for three.module.js, for example, it is a huge win.

[backspaces]

There may be an issue with minifiers and es6 format.

Could you explain the use case and issue further? You're trying to minify while keeping the file as an ES import, then importing it how? I guess I'm skeptical of the idea that just because minifying ES modules is difficult, libraries should ship a pre-minified ES module in addition to all the other output targets by default... it seems like this is a tooling issue that minifiers should solve. But perhaps I've missed something. :)

Just to be clear, the import statement with a minified file is the same as non-minified. So for my sample models, this works:

    import {
        ColorMap, Model, util
    } from '../dist/as-app3d.esm.min.js'

I've been using uglify-es to minify recently.

[donmccurdy]

I think I'd prefer not to add another output to the dat.gui build — not that I don't think minifying is worthwhile in the case you describe, but that I don't think it should be part of a library distribution. The bugs in minification tools will be fixed as ES modules become more common.