es6 modules

[backspaces]

Please consider es6 modules.

The easiest way to do this is simply convert to modules and use rollup to convert to any desired format: iife, cjs, and so on:
https://medium.com/@backspaces/es6-modules-part-1-migration-strategy-a48de0b7f112

It is surprising how flexible this makes your repo.

No worries if this is low priority, there is always this:
https://medium.com/@backspaces/es6-modules-part-2-libs-wrap-em-up-8715e116d690

[backspaces]

BTW: would gpu.js work with this node headless webgl?
https://github.com/stackgl/headless-gl
I ask because a module based repo could rollup to cjs, node's "require".

[robertleeplummerjr]

The better target for node is opencl for what we're specifically doing.

[robertleeplummerjr]

I believe the ./src directory is node module based, can you confirm? We provide ./dist and ./bin for es5 and web

[backspaces]

Yes, I believe the entire repo is node cjs module based and uses browserify to convert to browser use. And excuse the node mention, the high order bit here is gpgpu computation in the browser! Sorry.

The wish for an es6 module version is simply that lots of us are now using modules and are converting to having them be the core architecture, then use Rollup to convert to any format you want. I.e. if you write in the most modern JS, es6 & modules, there are workflow tools to convert to any target you'd like: es5, cjs, even es6 bundle of the repo.

Two articles on the topic:
https://medium.com/@backspaces/es6-modules-part-1-migration-strategy-a48de0b7f112
https://medium.com/@backspaces/es6-modules-part-2-libs-wrap-em-up-8715e116d690

It turns out the second method, tho a hack, may work for GPU. It basically would take your bin/ js files and "wrap" them in a module. But the first method is starting to take off .. a huge project I'm involved with took the time off to do it (about 4 days) and they really like the results.

And after all that serious stuff, THANKS! What a great idea.

[robertleeplummerjr]

So is the recommendation just as simple as changing:

• imports to use import something from 'somewhere'
• exports from using module.export = to export default or export {}

?

[backspaces]

Basically, yes. But then it also depends on the rest of your workflow.

Biggest differences is that es6 modules are static "declarations". Imports must occur before any code, at the top of the module's file. Exports can exist anywhere.

This can be an issue if you are using dynamic cjs imports now.

[robertleeplummerjr]

I believe because we are on release candidates, and because it would likely have breaking changes, we'll probably have this in v2.

[backspaces]

Absolutely agree. I'll try my "wrapper" solution sometime soon and let you know if it works.

[robertleeplummerjr]

Implemented as in v2 rc13:

import { GPU } from 'gpu.js'.

[logixoul]

@robertleeplummerjr I tried this in Chrome and got:

Uncaught SyntaxError: The requested module '../gpu-browser.min.js' does not provide an export named 'GPU'

[robertleeplummerjr]

@logixoul what version? Can you provide a reproduction script?

[logixoul]

@robertleeplummerjr
Here you go :)
test1.zip

GPU.js version: 2.9.3
Chrome version: 80.0.3987.163

[robertleeplummerjr]

Yea, you are dead right, it seems I overlooked that the files must use import/export and that browserify simply doesn't provide a means. There as some effort to migrate to es6 here, which may give us that ability.