Giter Club home page Giter Club logo

cake's Introduction

Cake

We are aware of Xcode 11, probably don’t commit to Cake at this time

Modules are a powerful Swift feature, yet existing tooling makes modulizing your projects so tedious that most people don’t bother.

A modular app gains:

  • Encapsulation. Internal scope is a criminally under-utilized Swift feature that makes encapsulation significantly more achievable.
  • Namespacing. Modules have an implicit namespace; fear not about reusing names, modulize instead.
  • Hierarchy. Once you start creating modules you automatically arrange them so that some have more importance than others. This naturally leads to a structured codebase where new files nestle into their logical, encapsulated homes, effortlessly.
  • Organization. You no longer have to cram everything concerning an area of responsibility into a single file to gain from file-private. Instead separate all that code out into multiple files in its own module and use internal access control.
  • Testability. Making a piece of functionality its own module means you can make more of that module internal scope rather than private and this means more of the module can be imported @testable making the functionality easier to test without adopting practices that make your code less readable for the sake of testing (like injection).

Cake makes working with Swift modules a breeze.

Xcode 10.2-beta Required

Supporting Swift tools-version-5 and tools-version-4 is not our thing. Cake requires at least Xcode 10.2 to function.

Support Cake’s development

Hey there, I’m Max Howell, a prolific producer of open source software and probably you already use some of it (I created brew). I work full-time on open source and it’s hard; currently I earn less than minimum wage. Please help me continue my work, I appreciate it 🙏🏻

Other ways to say thanks.

How it works

“The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small, manageable tasks, and then starting on the first one.” —Mark Twain

Cake is an app that runs in your menu bar and watches your Xcode projects. If you chose to integrate Cake into your App’s xcodeproj it will automatically generate your module hierarchy based on your directory structure. For example:

.
└ Sources
  └ Model
    ├ Module1
    │ ├ a.swift
    │ └ b.swift
    └ Module2
      ├ c.swift
      └ d.swift

Now ⌘B and you’ll be able to import:

import Module1
import Module2

FAQ: What is a cake project? A Cake project has a Cakefile.swift file in its root.

Delicious: All your modules are built statically so there’s no launch-time consequences.

Curious? Cake is made with Cake, so is Workbench, check out the sources to see more about what a cake‐project looks like.

Details: Cake generates a sub-project (Cake.xcodeproj), you lightly integrate this into your app’s project.

Module hierarchies

“You’ve got to think about the big things while you’re doing small things, so that all the small things go in the right direction.” —Alvin Toffler

Before long you will need some modules to depend on others. This is an important step since you are starting to acknowledge the relationships between components in your codebase. Cake makes declaring dependencies as easy as nesting directories.

.
└ Sources
  └ Model
    └ Base
      ├ a.swift
      ├ b.swift
      └ Foo
        ├ c.swift
        └ d.swift

Here Foo depends on Base and thus, Foo can now import Base.

All other tools require you to specify relationships cryptically, either textually or with a confounding GUI. With Cake, use the filesystem, relationships are not only easy to read, but also, trivial to refactor (just move the directory).

Further Reading: Advanced module hierarchies

FAQ: What should go in your Base module? Cake’s Base module contains extensions on the standard library.

Dependencies

“You can do anything, but not everything.” —David Allen

Cake makes using Swift packages in Xcode easy. Write out your Cakefile, ⌘B, Cake fetches your deps and integrates them: no muss, no fuss.

import Cakefile

dependencies = [
    .github("mxcl/Path.swift" ~> 0.8),
    .github("Weebly/OrderedSet" ~> 3),
]

// ^^ naturally, using Cake to manage your deps is entirely optional

We figure out your deployment targets, we make your deps available to all your targets and we generate a stub module that imports all your deps in one line (import Dependencies).

We check out your dependencies tidily, for example the above Cakefile gives you:

.
└ Dependencies
  ├ mxcl/Path.swift-0.8.0
  │ ├ Path.swift
  │ └ …
  └ Weebly∕OrderedSet-3.1.0.swift

Which generates this in your Cake.xcodeproj:

Which you can then commit, or not commit: that’s up to you. Though we suggest you do.

Delicious: All dependency modules are built statically so there are no launch-time consequences.

Delicious: A fresh clone of a Cake project builds with vanilla Xcode, no other tools (even Cake) are required. Distribute away without worry!

Delicious: Cake finally makes it possible to use SwiftPM packages for iOS development!

FAQ: Should I commit my deps?

Caveat: We only support SwiftPM dependencies at this time.

Further Reading: Cakefile Reference

Carthage & CocoaPods

If your app uses Carthage or CocoaPods we detect that and integrate them so your cake modules (the Batter) can use these dependencies.

Note, this only applies to cake modules (the Batter); for your App target follow the instructions provided by CocoaPods and Carthage themselves; nothing is different.

Op‐Ed—an era for Swift µ-frameworks?

CocoaPods and Carthage libraries tend to be on the large side, and this is at least partly because being modular has been historically hard and tedious when developing for Apple platforms and Swift. SwiftPM encourages smaller, tighter frameworks and using Cake means making apps with Swift packages is now possible.

Choose small, modular, single‐responsibility libraries with 100% code coverage that take semantic-versioning seriously. Reject bloated libraries that don’t know how to say no to feature requests.

Constructing frameworks/dylibs

Since everything Cake builds is a static archive, you can simply link whichever parts you like into whatever Frameworks or dylibs you need for your final binaries.

This is a purely optional step, statically linking Cake.a into your App (which Cake sets up by default for you) is perfectly fine. This more advanced option is available to make apps with extensions more optimal in terms of disk usage and memory consumption.

Installation

  1. Download it.

  2. Run it.

  3. Check your menu bar:

  4. Open a project and integrate Cake; or

  5. Create a new Cake.

FAQ: What does integration do?

Delicious: We auto-update!

Bonus Features

Extracting your app’s version from Git

Cake determines your App’s version from your git tags, to use them simply set each target’s “Version” to: $(SEMANTIC_PROJECT_VERSION) and if you like the “Build” number to: $(CURRENT_PROJECT_VERSION).

Delicious! We even append -debug to debug builds.

Xcode Remote Control

Caveats

Due to some Xcode bugs Cake is not a complete Cake‐walk in use. Please see our troubleshooting guide for details.

Documentation

Icons credit

Icons made by Google and Freepik from www.flaticon.com licensed by CC 3.0 BY.

cake's People

Contributors

abbasmousavi avatar krzysztofzablocki avatar kyle-fox avatar mxcl avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cake's Issues

Dependency names don’t always equal the repository name

Sadly.

So we need to determine the name with swift package dump-package before generating the Package.swift.

Which is problematic currently since we can’t resolve the graph before generating the Package.swift obviously.

Notably we only need this so we can use swift package generate-xcodeproj since it only builds the deps if we have a target that depends on them.

If we generated our own xcodeproj we wouldn't have difficulty of this specific kind at least.

How to share Modules between multiple projects

Sorry this must be a really basic question, but once i've built Modules (custom frameworks etc.), i would like to share them with my other projects.

What is the best practice to do this with Cake ?

Fill out FSWatcher

eg.

  • watch root for delete/rename
  • handle Cakefile.swift delete
  • handle empty modules, deleted modules

Clean/Rebuilds often required for changes in modules to be included

Seems like an Xcode 10.2 bug since I only noticed it then (saw others on Twitter say same).

  • Changes to model and deps only get put in final binary if clean build occurs
  • Pretty sure this wasn't always case so either Xcode 10.2 bug or our dependency logic is bust somehow.
  • Maybe worth trying making recursive deps explicitly specified.

Integration issues

  • If some cake stuff there, use, don't overwrite. But overwrite the Cake.xcodeproj
  • If already Sources/Model error

Not making modules of all folders.

I think that it is good to add the ability to not make all folders to modules in Batter, so that we can use folders inside a module to just organize code (not making modules).

Maybe we can have a way to flag a folder to say that I want this folder and all its subfolders just as a module?

Speed up build times

First of all, thanks for your work, the lib is very interesting.

Could we cache modules to speed up build times (like Buck does) ?

Failing to integrate or create new Cake

Thanks for putting this together!

We're running into issues with both creating a new Cake project and integrating an existing project with Cake. We get this message when integrating or opening a Xcode (Beta 4):

Screen Shot 2019-03-15 at 4 21 06 PM

Possibly related. When trying to build, we get this error:
The operation couldn’t be completed. (E.notCake(Path.Path(string: "{ path to the project }")))

Maybe we're doing something wrong? Tried on multiple machines and tinkered with some different build settings. No luck:/

Replacing static frameworks with swift packages

Is there any way to use swift package instead of static libraries to organise the code with Cake with Xcode 11?

The use case is that I want to use swift packages to organise my code into several separate swift module/packages and it is very easy and convenient with new Xcode.
The problem is that my code has some third party dependencies (pods) and it is not easy to use all this dependencies as swift packages, some of them are old or obj-c or closed source pods.

So if there was a way to make a set of pods available to all swift packages in the project, it was really useful, because I think it takes a long time for all pod developers community to make all pods available as swift packages.

Don’t assume git

We indiscriminately edit or create a gitignore for create/integrate. Expect other version control.

Check for .git first.

Consider "Sources•Modules" rather than "Sources•Model"

First, 👏thank you👏 for taking a shot at fixing the problem you're trying to solve! I'm frustrated by the tooling standing in the way of modularizing Swift codebases all day long every day. So, I really hope this tool takes off. 🎉


I may not be understanding everything (or much at all) so I'll break this up into my assumptions, my use case, and then my suggestion(s)...all based on those assumptions 😄

Assumptions

  • Everything in "Sources•Model" is compiled against all platforms in the Cakefile
  • Modules are not created for folders in "Sources•App"
  • There is currently no way to limit the platforms a specific module in "Sources•Model" is compiled against
  • The intention is for all platform-specific code to go in "Sources•App"
  • The developer is expected to create each application target (excluding the one the Cake menu app will create for you).

Use case

  • Large project, targeting iOS, macOS, tvOS, and watchOS
  • Non-trivial UI for each platform. Lots of view controllers, lots of "components" (similar to React, small reusable UI bits).

For my situation, micro modules would offer just as much benefit to my application-specific code as my domain/model code. In fact, my UI code would probably benefit even more. That is where I find myself using nested types for the sole purpose of faking namespaces more frequently than anywhere else. Nested types are fine, but I've found that Xcode/SourceKit/Something-else-in-the-tool-chain falls over after a certain depth and all I see is <<error type>> in Xcode's autocomplete dialogs.

Suggestions

  1. Add support for limiting which platforms a specific module is built for. Maybe that takes the form of a Cakefile in a module's directory, or platform-specific "Sources•Modules•[platform]" directories...which could be auto generated using the platforms setting in the root Cakefile. The goal being platform-specific-modules in a multi-platform project.
  2. Rename "Sources•Model" to "Sources•Modules"

To be clear, this is only necessary for a multi-platform project. What I'm wanting to do is already totally doable for a single-platform project.

Dependencies.xcodeproj depends on Cakefile target

Without fixing this a variety of issues can occur.

Options seem to be:

  1. Regenerate Cake.xcodeproj from within (can detect this and rebuild controlled from Cake.app with AppleScript)
  2. Try to depend on Cakefile’s target in Dependencies.xcodeproj. This is an Xcode project reference cycle however and may have consequences.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.