Currently gun is using self-developed tool to make it run on both browser and node. These years JS has envolved a lot.
It's time to use ES6+ syntax to define classes, ES Module to require files (instead of Gun's unbuild). unbuild doesn't work well with modern toolchains like webpack etc.
Up to time codebase will help contributors more easily to contribute to the gun.
@amark Would you like to accept the pull requests if anyone migrates gun codebase with these features?
+1 on a module system, but we'd have to produce simple files too so that those still could be used with a <script>-Tag import
on TypeScript: I think adding the type-defs to the package would be possible a completely re-write would be another topic^^
CI: Travis allows free accounts for open-source repos
I appreciate the willingness to make an ES6 version.
The best place for this to go is as a new separate module / repo that the community can maintain.
Asking me to maintain code that requires a compile step to work in the browser would make me lose hours of daily productivity. I understand other people like these tools, and I'm happy for other people to use them, but it is not fair to force me to use them - I have already had to use them for other projects I have helped people with, and they brought me a lot of pain and misery.
I'd rather adopt a real programming language, like Rust, if I'd have to work with a compile-to-JS/WASM. I want to be clear, I write pure JavaScript because it can run in any browser out of the box without compiling. If your code cannot do that, it is not JavaScript, you're likely wasting your time and I encourage you to use Rust.
If people are serious about this, it is simple and I won't be offended to write an ES6 port of GUN, and can be done in a few hours based on https://gun.eco/docs/Porting-GUN , and the community will adopt it. But I absolutely do not have time to maintain its code (unless I get paid my full going rate upfront), and therefore must be branded as a community port. GUN is open source and my priority is focused on delivering real value to end users, scaling, and performance, not whether I'm using semicolons or not - I respect those who do, but please don't drag me into it, I've been there in the past and all it did was hurt everyone involved.
Okay, first of all, I think npm run unbuild is also some type of build step.
With no toolchains, ESModule can run in:
<script type="module"> import Gun from './gun.mjs' </script> (Only in http or https, not file://.)node --module ./server.mjsI'd love to see an ES6 port, you do not need my permission, please go do it! I just don't have time to be liable for any of its code or the tremendous number of support/debugging hours it results in.
unbuild is not needed to be run for either NodeJS or Browser to work. It is literally only there to appease Webpack lovers.
type='module' has very poor support world wide ( https://caniuse.com/#feat=es6-module ).
We already use Travis.
I'll add the ES6 port to the list of languages, please send repo link.
I mean you can develop with type=module without any build step and since you have a prepublish script after all, rollup or webpack can make a single file version for production using in browser and node.
esmodule is simple enough and you won't need to "debug" on it. Also esmodule is independent with other es6 features you can adopt it and leave all other codes untouched.
And I think there is no meaning to fork a repo and make it ES6 but not merging back.
@Jack-Works, what if we update the unbuild process to allow for ES Module exports?
@Jack-Works, what if we update the unbuild process to allow for ES Module exports?
I don't think it can be done with changes on unbuild. ES import-export needs its' own syntax
In commonJS, you do this module.exports.A = 123
In ESModule you do this export var A = 123 where export is a keyword
@Jack-Works Seems like we could place ES module declarations inside of block comments in gun.js and update unbuild.js to remove /* and */ around the export statements. USE statements currently get replaced with require, we could update this to generate import statements instead.
I'm not sure if replacing the require statements will break anyone's builds. Perhaps we could target a folder called esmodule instead of src, for the time being.
I've started experimenting already. Your thoughts?
@rm-rf-etc this should work perfectly! Brilliant, I love it.
If NodeJS (?) already supports import then unbuild could just swap require for import with some minor semantic tweaks. Or even, yeah, a comment if that simplifies things.
Is there any point to using require anymore in NodeJS? If there is, we could just generate both easily, like you're saying.
Also, people much smarter than me @r14c @Kuirak got a minimum working version of import running here: https://github.com/amark/gun/issues/636 .
It looks like based on there expertise, we would need to generate 2 different code versions.
For help
import { createRequire } from 'modules'
const require = createRequire(import.meta.url)
then you can use require in node + esmodule
I was able to output the unbuild files with ES module imports and exports, you can see the result here.
This actually builds with zero errors, but an error throws at runtime; some issue with _ not being available. Have not looked into it yet.
@amark ES modules are still not supported natively in nodejs.
https://nodejs.org/api/esm.html#esm_ecmascript_modules <- experimental, flag enabled
@rm-rf-etc MIND BLOWING! :D :O epic!!
Please let me know when we should start merging. (es_modules may be too ugly of a folder name for me tho lol, would just es6 work? Or could we nest it in src/ or somewhere else?)
@rm-rf-etc MIND BLOWING! :D :O epic!!
Please let me know when we should start merging. (
es_modulesmay be too ugly of a folder name for me tho lol, would justes6work? Or could we nest it insrc/or somewhere else?)
esm would be best.
or module
@Jack-Works I think I have a successful build using webpack and ES modules. Could you give this a try? https://github.com/amark/gun/pull/796