a pure es module import would be fantastic

I frequently like to use dat.gui in small experiments on my local machine. I'd love to not need to have a package manager to install/build/configure dat.gui for these fast experiments.

Here is how I'd like to use dat.gui:

<script type="module">
    import dat from 'https://cdn.jsdelivr.net/gh/dataarts/dat.gui@0.7.7/src/dat/index.js'

    const obj = { x: 40, y: 100 }

    const gui = new dat.GUI()
    gui.add(obj, 'x')
    gui.add(obj, 'y') 
</script>

Right now this snippet won't work because the source code doesn't include the file extension when it imports modules (.js)

This would be really amazing for prototyping, just being able to wire up this usage of dat.gui without all the ceremony of needing node, npm, bundling tools, bundling config, etc.

I guess the files need to be renamed to extension ".mjs", so they're compatible to both Node.js' NPM and browser environments:

https://2ality.com/2019/10/hybrid-npm-packages.html

My understanding of .mjs is that it's a workaround that was used in/proposed by node, before they added es modules support.

We could potentially use .mjs but at this point it might be better to stick with .js. .mjs isn't technically a known MIME type.

You'll need to import the final build ES6 module, not the source files, to use the module in a browser. Try:

https://unpkg.com/dat.gui@0.7.7/build/dat.gui.module.js

Thanks for the link!

I'm curious why the es6 build doesn't use let, const, or other es6 nice-ities? This seems to be transpiled down to an older javascript dialect (es5?)

The purpose of the build is to provide an ES module — it's not meant to be any different otherwise than the CommonJS module version.

The purpose of the build is to provide an ES module

yeah I get that, I guess what I mean is, es module support was one of the last things to go into es 6, so if the output target of build/dat.gui.module.js is es module based, why not leverage other capabilities that are also in es6?

not the source files,

A pity though. B/c by adding the extension ".js" to something like import Color from './color/Color';:
import Color from './color/Color.js';

Throughout the source https://github.com/dataarts/dat.gui/blob/master/src/dat/index.js

It would allow us to use import directly on "dat.gui"'s source like this:
import dat from 'https://unpkg.com/dat.gui/src/dat/index.js'

by adding the extension ".js" ... it would allow us to use import directly on "dat.gui"'s source

It isn't quite that simple: the build process also includes the .scss files used to style dat.gui. The build outputs are meant for distribution on npm and on CDNs, but the source code is not. See:

dat.gui/src/dat/gui/GUI.js

Line 28 in 071edeb

import styleSheet from './style.scss'; // CSS to embed in build

es module support was one of the last things to go into es 6, so if the output target of build/dat.gui.module.js is es module based...

If you're importing scripts from a CDN, sure. But users may be using ES imports in ES5 code, and relying on something like Rollup to strip the imports without fully transpiling the code. Bundlers like Rollup handle import/export by default, but require additional plugins to fully transpile other parts of ES6 or ES7.

I'm not saying this is the "right" way to do this — that's subjective. But today this project's CommonJS and ES module builds are both compiled to ES5, which is the default behavior of rollup-plugin-babel, and I'd prefer not to drop that backward-compatibility without a compelling reason.

I'd prefer not to drop that backward-compatibility without a compelling reason.

Yeah I'm not asking anyone to drop backwards compatibility. :) I'm just asking if we could provide a "pure" es modules based thing alongside all of our existing stuff, which would enable me to drop node/npm/package.json/build tools/legacy module formats, etc.

with the advent of good browser support + deno, now seems like a prime time to start re-evaluating the way we've been doing things for the last decade of javascript.

The build published under the module entry (i.e. https://unpkg.com/dat.gui@0.7.7/build/dat.gui.module.js) is an ES module, written in pure JavaScript, compatible with all modern browsers. You don't need any build tools to use it. The fact that it doesn't contain let/const or ES6 Classes doesn't really seem like it should be holding your project back, correct?

I've shipped modern ES6+ in other libraries, and I have no problem with that practice, but I think this project's use of ES5 is reasonable and sufficient. This is, after all, a library dating back to 2004.

I'd prefer not to add another build output unless there is a clear way to make it useful, e.g. a modern entry in package.json. That doesn't exist today, but perhaps will in the future: https://twitter.com/_developit/status/1263174528974364675.

The fact that it doesn't contain let/const or ES6 Classes doesn't really seem
like it should be holding your project back, correct?

Well, I didn't open this issue because I'm held back. :) I have dozens of projects that have been using an npm based build chain. And I'm certainly able to use dat.gui in all kinds of existing projects. (dat.gui is a great tool by the way!)

On the other hand, just because things work doesn't mean they are optimal, and won't stop me from continuously evaluating how I can improve tools and libraries I rely on. :)

Ok — regarding the original question of the issue, we do provide a "pure ES module import" as explained above. Publishing a build (whether it uses ES imports or CommonJS imports) that uses other new ES6 features, rather than ES5, I see as a separate question. For the time being I am not willing to make that change.

regarding the original question of the issue, we do provide a "pure ES module import" as explained above

sounds reasonable, thanks for your time!