search

ACRA / acralyzer

Open source backend for ACRA reports.
GNU General Public License v3.0
489 stars 90 forks source link

Build Script Support #14

Closed halkeye closed 11 years ago

halkeye commented 11 years ago

I'm a big fan of http://gruntjs.com/ for automating build steps. My Plan is to add grunt scripts to package up the code into a nice small package for couchapp deployment.

The bigger this app gets, the more files it'll have to keep readability/testability/etc. This will lead to slower load times as we have to load each file when the app is loaded.

Grunt has some great tools for concatenating and minifying files into smaller chunks. This means for development we can have many files, but deployment only have 1 file with all the angular code.

I am proposing migrating all the code do a different directory, lets say src, and having grunt build the _attachment directory of just files we need. We can still commit the _attachment directory so people can easily launch but it'll be minified and streamlined.

(I'm creating an issue for discussion purposes)

KevinGaudin commented 11 years ago

That's great, I wanted to do this someday but have no knowledge about the whole process. Go ahead !

Source code in src and build going to _attachment is exactly what we need. We just have to couchappignore src.

halkeye commented 11 years ago

grunt can support documentation as well (ex https://github.com/dpashkevich/grunt-jsduck)

halkeye commented 11 years ago

Oooh. I can probably get something setup so we can embed git version hashes into the code somewhere for debugging purposes.

halkeye commented 11 years ago

Hey @KevinGaudin

I have a grunt file all setup but its kinda waiting on yeoman/grunt-usemin#73 but I've heard the maintainer is away this week.

I'm not worried about a delay, but since its doing some decent sized changes to index.html, i'm figuring it might be a merge nightmare if too much time passes.

What are your thoughts?

halkeye commented 11 years ago

Options are:

KevinGaudin commented 11 years ago

With this build system, it will be more complicated for newcomers to get the repository and deploy their app if they have to install node.js/npm/grunt.

We would have to deliver a simple tarball containing the generated couchapp.

About the grunt-usemin issue... I don't know... is the symlink solution working nicely ?

halkeye commented 11 years ago

I'd recommend including _attachments in git anyways. Also it can be argued that people prefer having "stable" releases as tarballs as you never really know the state of git branches.

The symlink thing would just be for a week or so until bug is fixed. It can, and probably should wait, but its just really cool to have a background grunt watch process running running jshint and uploading to local couch dev server every time a file changes.

KevinGaudin commented 11 years ago

Agreed. ;-) Le 1 mars 2013 22:31, "Gavin" notifications@github.com a écrit :

I'd recommend including _attachments in git anyways. Also it can be argued that people prefer having "stable" releases as tarballs as you never really know the state of git branches.

The symlink thing would just be for a week or so until bug is fixed. It can, and probably should wait, but its just really cool to have a background grunt watch process running running jshint and uploading to local couch dev server every time a file changes.

— Reply to this email directly or view it on GitHubhttps://github.com/ACRA/acralyzer/issues/14#issuecomment-14312579 .

halkeye commented 11 years ago

So is your vote to wait for usemin? or pull request with symlink to start?

KevinGaudin commented 11 years ago

I prefer a workaround over an unofficial patch. Let's go with the sum link. Le 1 mars 2013 22:56, "Gavin" notifications@github.com a écrit :

So is your vote to wait for usemin? or pull request with symlink to start?

— Reply to this email directly or view it on GitHubhttps://github.com/ACRA/acralyzer/issues/14#issuecomment-14313729 .

halkeye commented 11 years ago

I thought about it. Maybe we are backwards.

The build file should be more for releases, not for development. I'm thinking code should stay in _attachments, but the build file will make a new filesystem in dist. That way a tarball could be created from that subdirectory.

That way if someone checks out the code they just get the non minified version. Just like they have now. I mean you wouldn't want to upload a minified version to a development server for testing/dev, so for dev you'd still want to upload the original source.

Does that make sense?

KevinGaudin commented 11 years ago

It does make sense, you're absolutely right. Le 2 mars 2013 05:43, "Gavin" notifications@github.com a écrit :

I thought about it. Maybe we are backwards.

The build file should be more for releases, not for development. I'm thinking code should stay in _attachments, but the build file will make a new filesystem in dist. That way a tarball could be created from that subdirectory.

That way if someone checks out the code they just get the non minified version. Just like they have now. I mean you wouldn't want to upload a minified version to a development server for testing/dev, so for dev you'd still want to upload the original source.

Does that make sense?

— Reply to this email directly or view it on GitHubhttps://github.com/ACRA/acralyzer/issues/14#issuecomment-14322890 .

halkeye commented 11 years ago

This seems to be done now due to #19 so closing.