hi,
On 07.01.2017 21:39, Lunar wrote:
One thing that is unclear to me for now: do you want to implement new features that require reimplementing the current JavaScript code? Except cleaner code, what is to be gained by switching to ES5?
Apart from becoming cleaner it also becomes testable, because right now I don’t really see how that would work out.
The js build system would introduce webpack as a build tool. Webpack receives an entry file, recursively resolves dependencies (import/require statements) and outputs a single js file that would be added as the only script tag in the rendered HTML page. It also supports a watch mode, so we could keep the original "just works™" behaviour if we spin up webpack when starting the development server.
I don't see a Debian package for Webpack. :(
Would you know of any Ruby library that would provide similar features? Packaging new gems for Debian is quite easy.
I see Debian as a ruby-uglifier package which is a wrapper for UglifyJS. I'd rather try to avoid adding a strict build dependency on Node.js. The above package requires Node.js for example.
The thing is that webpack does more than uglification (actually it doesn’t do uglification at all; it utilizes uglify). The most important part is the ability to resolve common-js modules. Debian has a browserify-lite package. That’s still node-js, but is included since jessie. Probably works too. That would leave out Babel for transforming ES6 code to ES5 but as that is mostly syntax I don’t see a problem with it.
From the top of my head: watch out for the Crowford (“don't use for evil”) license. It's non-free and caused us huge pain in the past.
Most node modules are MIT, but I keep an eye on it. Everything in Debian should work, right?
bye
konrad