Build Profiles

[garzaCodes]

This is a Feature Request.

Request: It would be nice to be able to create Build Profiles within Codekit. It's nice that I can setup a default build for all new projects, but a lot of times I am working on projects that require different Build Steps. I realize this can be done on a project by project basis, but it would be nice to just be able to save different build profiles and have a choice to choose from a drop-down rather than only being able to build each project's steps manually.

Thanks for all the great work. CodeKit3 is awesome!

[luxlogica]

Ok, I don't know if I understood this correctly, but I see these 'Build Profiles' as pre-defined build configurations that we can quickly auto-load, rather than having to recreate the build steps on every project.

I deal with 2 different CMSs, and they both require several, quite different, build steps. Being able to auto-load a pre-configured set of build steps for each CMS would actually be very, very handy.

[greystate]

Would love something like this too

[bdkjones]

Generally, I’d recommend using Branches in Git to accomplish this. A debug branch and a release branch, for example. Each with different settings.

I’m also a very strong proponent of “build like you’ll release, all the time”. If you wait until the end to turn on minificafion, for example, you might not catch bugs you otherwise would.

Sent from my iPhone

On Feb 1, 2018, at 03:03, Chriztian Steinmeier [email protected] wrote:

Would love something like this too

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[luxlogica]

@bdkjones Not sure I understand: how can we use git branches to pre-load similar build steps on several projects? I think that would be the purpose of 'Build Profiles'.

For example: for many projects we use a flat-file CMS that stores all the site's content in a 'content' folder. When we do a 'build' in CodeKit, we normally want the 'build' folder to be erased, and everything rebuilt from scratch. The 'build' folder, however, is also the 'staging' folder - the folder where all the 'staging' content also is (which may include content the client has already added themselves, to go into the production site). So, we have a sequence of build steps that we use for every project where we use this CMS. The sequence goes:

• copy 'build/content' folder into a 'temp' folder
• delete 'source/content' folder
• copy 'temp' into 'source/content' (that means we also have the latest version of content in 'source', too
• clean out 'build' folder
• build
• copy 'temp' into 'build/content'

As you can imagine, having to enter all of these steps manually every time we have a project using the CMS means that some developers prefer to simply NOT use a build system at all. If we were able to 'pre-load' these steps from a "Build Profile", that would be incredibly helpful.

[bdkjones]

Ah, I see what you mean. I thought you meant that you wanted, for example, a JS file to be minified in one "profile" and unminified in another.

You're using custom build steps in CodeKit to do the above? Can you send me a demo project that shows them? I'd like to use that to build a feature to enable this.

[dwkns]

@bdkjones @luxlogica This would be a very useful feature. When developing something big and complex I often create a separate tiny project to develop / test a particular feature in isolation. The process of getting this set up can be a bit arduous.

Maybe it could be something like a codekit.config.json (or better still codekit.config.js so we can add logic) we can manually add to the root of a project with base settings included.

When the project folder is first added to CodeKit the config file is read and it populates CodeKit settings.

{
    "buildFolder": {
        "useBuildFolder": true,
        "sourceFolderName": "path/to/source",
        "buildFolderName": "path/to/build",
    },
    "skippedFolders": [          // not indexed
        "node_modules", "_cache", "log",
    ],
    "ignoredFilesAndFolders": [               // not processed
        "node_modules", "package.json", ".babel.rc", "yarn.lock", "source/js/tests/**"
        "source/scss/useful-mixins.scss"
    ],
    "indivdualFileSettings": [{          // settings for individual files.
        "file": "source/js/main.js",
        "onChange": "process",          // ignore / copy / process
        "output": "build/js/main-min.js",
        "options": {
            "checkSyntaxWith": false,
            "transpileWith": "babel",
            "minify": true,
            "generateSourceMap": true,
        }
    }, {
        "file": "source/scss/main.scss",
        "onChange": "process", // ignore / copy / process
        "output": "source/css/main.css",
        "options": {
            "outputStyle": "Nested",
            "useLibsassComiler": "babel",
            "minify": true,
            "generateSourceMap": true,
        }
    }],
    "buildSteps": [{
        "type": "processFiles",
        "files": ["path/to/someFile.ext", "path/to/anotherFile.ext", ]
    }, {
        "type": "script",
        "scriptType": "shell",
        "script": "echo \"Hello world\""
    }],
    "hooks": [{
        "name": "fancyHookName",
        "type": "applescript",
        "trigger": "path/to/something",
        "script": "display dialog \"AppleScript ran\""
    }, {
        "name": "Another Fancy Hook",
        "type": "shell",
        "trigger": "path/to/something",
        "script": "echo \"Hello world\""
    }]
}

It would be even better if you could output these settings when you have a project structure set up the way you want too. That would make creating new project templates much easier.

[dwkns]

@bdkjones @luxlogica more thinking on this...

Could you expose Project Settings & Files to AppleScript? That way we would programatically set up a project along with it's settings.

Something along the lines of...

tell application "CodeKit" 
    add project at path "/somepath"
    set projectSetting "tools" to { babel: { enableSupportForReact: true }  } 
    set projectSetting "language" to { javascript: { checkSyntaxWith: "ESLint" } } 
    set fileSetting of "/some.file" to { generateSourceMap:true, changeOrBuild: "ignore"}
    add hook "shellscript" with properties { inputFullPathContains: "/some.file", text:"fancy bash commands"}
end tell

Or combined with my last comment...

tell application "CodeKit" 
    set projectSettings to (read POSIX file "/path/to/projectSettings.json")
end tell

[bdkjones]

Mmm, maintaining that API contract would be a nightmare moving forward.

The basic idea has been on my list for a while: set up a "scaffold" project just the way you want it, then save it so you can clone it later to quickly spin up a new project with that same setup. This is definitely on my list.

[dwkns]

Figured it would be. A lot of work for an edge case.

The scaffold idea is what I'm sort of doing at the moment. I've set up a skeleton project on GitHub with files/folder structure with a saved .codekit3 file for all the settings. Then I use a bash script (aliased to iws in my .bash_profile) to get things set up. It actually works reasonably well for this use case.

[iocouto]

Either 'Build Profiles' as described by @luxlogica, or 'Project Templates' - a 'scaffold' project - as described by @bdkjones would be immensely helpful. The main idea being, that you can 're-use' your settings - including previously defined build steps - without having to recreate everything from scratch.

Seeing that the last comment here was 3 years ago, and that this feature request is almost 5 years old, is it still in the cards?...