[Coquelicot] coquelicot contributions

Konrad Mohrfeldt kmohrf at systemausfall.org
Tue Jan 17 21:29:39 CET 2017


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


More information about the Coquelicot mailing list