couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Kowalski <...@kowalski.gd>
Subject Re: Fauxton Windows developer question
Date Wed, 28 Oct 2015 00:36:39 GMT
Hi Joan,

thanks for the input. That is a good reason not to use Makefiles.

Hi Sebastian,

thanks for the response.

One thing I stumbled upon was that a production release is created
from the code the dev-server creates in the debug folder, but only
parts of it. (the compiled css and static assets are taken from
dist/debug -- while the js is taken from app/)

Transpiled JS code is created next to source code in the same folder -
which is then used to create a production release using requirejs in
the source dir plus transpiled less from dist/debug and other assets
that the dev-server (which serves the dev environment) creates(!). The
way how different filetypes are compiled, to which target they are
compiled and how output from our debug-server is used for production
releases makes it hard to understand and maintain the Gruntfile,
especially if you try to compose parts of it. As I already mentioned,
it is nearly impossible right now to switch to babel. A brush up would
be nice, but it means a rewrite of large parts of the Gruntfile
anyway.

Sadly that is not the only big issue we have, another issue is that
every `npm install` will build a production release on the client in
order to provide a standalone Fauxton installation. The way it should
work is that an "npm publish" creates a release artifact which gets
published to npm and contains everything that is needed already,
including the transpiled code for standalone installs.

I could go on with other issues that annoy me right now and are quite
different to standard build/release processes.

Why are the paths on the filesystem for dependencies like a swf file
not transparent to the Fauxton app? Instead the app itself knows if it
(the app itself) is a bundled release or not and decides at runtime(!)
based on this state which dependency it should include from where.
This is another workaround to deal with the different locations of
static assets in dist/debug (swf, fonts, images and css) and the
js-sourcefiles in app/ which are differently used for releases and the
debug server. It is important to note that we need this workaround
because it is not possible to fix the root cause in a proper timeframe
without rewriting large parts of the way releases are built.

Regarding grunt, Gulp & friends: this post sums my problems with
Grunt&Co up very well:
http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/ - it
just takes 5min to read and I could not have written it better.

I already spent multiple hours of work trying to brush up our
Gruntfile, and because I keep running into walls with it was the
reason why I wrote the initial mail.

I go with splitting out small parts of the build process and make them
composable, independent of the current task runner. We can use them as
standalones on the console or in Grunt, like we do with other tasks
already [1]. It just felt a bit odd to reimplement a `$(shell find
app/ -name '*.less')` in 9 lines of JavaScript [2] -- that is why I
had the idea to use a Makefile, next to the nice fact that builds with
make are idempotent. shelljs looks interesting for tasks like finding
all less files in a folder, I will try it out and maybe use it.

Best,
Robert

[1] https://github.com/apache/couchdb-fauxton/blob/master/Gruntfile.js#L390
[2] https://github.com/apache/couchdb-fauxton/blob/master/Gruntfile.js#L77-L86

On Mon, Oct 26, 2015 at 9:59 PM, Sebastian Rothbucher
<sebastianrothbucher@googlemail.com> wrote:
>
> Hi,
>
> if it was me, I'd avoid plain makefiles, too. At least for fauxton. What
> about sticking with Grunt? We could still do some work to brush up the
> Gruntfile. And with a few tweaks, it's portable, even on Win (in fact: I
> found another one this WE).
>
> Best
>     Sebastian
>
> On Tue, Oct 20, 2015 at 6:03 PM, Joan Touzet <wohali@apache.org> wrote:
>
> > Hi Robert,
> >
> > I'm presently migrating our one Makefile left in couchdb to a Windows
> > NMakefile, which uses a different syntax.
> >
> > git shell works but has enough problems that I don't want to rely on
> > it. Sometimes it's almost as much work to debug a GNU Makefile running
> > under cygwin as it is to rewrite the entire Makefile as an NMakefile.
> >
> > It'd be super swell if you could avoid a GNU Makefile.
> >
> > -Joan
> >
> > ----- Original Message -----
> > > From: "Robert Kowalski" <rok@kowalski.gd>
> > > To: dev@couchdb.apache.org
> > > Sent: Tuesday, October 20, 2015 10:12:17 AM
> > > Subject: Fauxton Windows developer question
> > >
> > > Hey there,
> > >
> > > I am currently working with our old & grown Gruntfile.js [1] together
> > > with
> > > the files in tasks/
> > >
> > > The gruntfile has grown over the years and it got really hard to make
> > > changes to our buildsystem.
> > >
> > > It also has some weird edge cases, as a release is made from the
> > > dist/debug
> > > folder, but the debug folder and it's contents is created from the
> > > task
> > > that spins up the devserver.
> > >
> > > Anyway... right now I am trying to integrate Babel as react-tools are
> > > deprecated. After the update I want to update to React 14 (that's
> > > where my
> > > current journey began).
> > >
> > > There are some tasks that would perfectly fit into a Makefile because
> > > they
> > > don't fit in a one liner as `npm run <task>` [2] (e.g. finding all
> > > .less
> > > files and feed them into the less compiler). I know that some people
> > > are
> > > using Windows and I am a super Windows noob.
> > >
> > > Windows Fauxton developers:
> > >
> > > Do Makefiles run in your Windows dev environment (e.g. via git shell
> > > et.
> > > al.) or would a make based build for Fauxton exclude you?
> > >
> > > If it would exclude you, do you have a suggestion what to use?
> > >
> > > Best,
> > > Robert :)
> > >
> > >
> > > [1]
> > > https://github.com/apache/couchdb-fauxton/blob/master/Gruntfile.js
> > > [2]
> > > https://github.com/apache/couchdb-fauxton/blob/master/package.json#L50
> > >
> >

Mime
View raw message