Recursively generate dependency providers for all unique paths from a component. This only generates the shell of the provider with name, dependency protocol and path.

The PluginizedLifecycle should determine when the scope is ready to be released instead of through the additional builderWillDeinit method. This also removes the concept of "Builder" out of Needle, since not all applications have such a concept.

Currently generated code does not include imports. These are required for the generated file to compile.

In 0.8.1 it looks like the sample projects schemes have changed to "Shared" if this is the case then Carthage will try to build the project, this build will fail because carthage update has not been run in the sample directory.

The current Why DI document explains only the benefits of writing loosely coupled code using the DI pattern but doesn't offer any details on how needle specifically helps or why anyone would want to use a dependency injection library in general.

Because Needle needs to parse instantiations of Component to generate the DI graph, if a Component is instantiated outside of a parent Component, Needle may miss a path. A missed path will lead to a runtime error of missing dependency provider.

At the same time, simply parsing all source code is not enough to gather all DI paths, because SourceKit cannot provide all type information. For instance, the code below would require a global static analysis to retrieve the DI path:

func globalFunToCreateComponent(withParent parent: ComponentType) -> MyComponent {
    return MyComponent(parent: parent)
}

The actual type of the parent component of MyComponent is unknown until a global static analysis is performed. This would significantly violate Needle's performance requirements.

ContentFilter only allows files with Component subclasses to pass. Protocols inheriting from Dependency and PluginExtension should also be parsed.

I would love to give it a try and maybe contribute to this project.

How am I suppose to use it? Is there some wiki page or should I look at the code?

Btw, thanks guys, highly appreciated for these efforts.

Various other code generation tools support CocoaPods as an installation option. e.g. Sourcery, SwiftGen, SwiftyMocky, etc. This makes it easy to onboard new team members since they can just run a pod install and the binary gets downloaded and the run script just runs it from the Pods directory.

Setup the generator project as a sibling project to the framework project, to host the parser and generator classes.

Currently needle does not parse the extensions of a Component. All your code needs to live in the FooComponent class definition. If you have some reason to put some of the vars in a extension FooComponent (e.g. you like organizing things this way) then the current version just ignores these properties.

Would be nice if, for all the known Component subclasses, needle considered any extensions made to these subclasses.

Add the parent pointer based on the child expression call parsed in #58

Based on single responsibility principle, DI components help encapsulate dependencies.

Needle cannot connect components and dependency protocols that are private or fileprivate. This will cause silent failures. We should print out warnings for these cases.

This means the generated code will switch around without any changes to the input -- which is pretty annoying.

Also, this means our unit tests are actually flaky at the moment due to this.

This is caused by Dictionary key order not being stable.

The order of key-value pairs in a dictionary is stable between mutations but is otherwise unpredictable.

From : DIctionary reference

Make sure to explain the resulting confusing folder structure in the top-level README.

I see that #3 has disposed of RIBs as something that would unnecessary complicate the tutorial / example project and even obscure the subject matter. Nonetheless, it is my sincere desire to learn more about the best-practice workflows that exist when using Needle to manage RIBs components.

🎉

Need to add support for custom header doc for things like disabling linters and marking files as generated for Uber specific use cases.

//  @generated by Needle
//  swiftlint:disable custom_rules

Hashing in Swift 4.2 is no longer deterministic. This would break unit tests and cause generated code to constantly change. We should switch hashing path to SHA path.

Push Needle to pod repo, since we have the podspec now.

It's unlikely for this to occur, therefore, instead of formally supporting this, we'll just exit. If we need to support this in the future, we can just use the hash of the file path.

My understanding is that a lot of the force unwraps/fatalerrors in Needle are expected to never crash because the code generator will ensure that they always succeed.

It would be useful for code reviewers without a lot of context, or for users who might be debugging crashes in Needle, to know which code is guaranteed, and which code is potentially dangerous.

This could take the form of new method of force unwrapping, for example:

extension Optional {
     var guarenteedUnwrap: Wrapped {
          return self!
     }
}

Or just be a commitment in the Needle Code Standard (if/when they're written) to only force unwrap when the result is guaranteed to succeed.

Currently warning messages are always printed out. We should accept a command line argument to silence all logs.

At the same time, we should turn warning messages into closures to allow lazy evaluations. This means running in silence mode, we don't even have to create the Strings.

When I use Google Swift Style Guide to write code, it has a column limit of 100 characters. So i will line-wrapping like this

public final class SignInComponent: PluginizedComponent<
  SignInDependency,
  SignInPluginExtension,
  SignInNonCoreComponent
> {
  //...
}

But needle can't Recognition these generic arguments, can't generated Dependency Provider code in Factories.

When I write all generic arguments in one line like sample code, it work better.

public final class SignInComponent: PluginizedComponent<SignInDependency, SignInPluginExtension, SignInNonCoreComponent> {
  //...
}

Hope to support different Swift Code Style.
My needle version is v0.8.5.

Setup the framework project and Implement the base vanilla Component class.

A component may have multiple parents. Its parents can also have multiple parents. This means a dependency the said component requires must be satisfied at all the ancestor paths. Each of these paths require a different DependencyProvider since the runtime object acquisition paths are different. The current implementation only uses the component itself and its parent as key to retrieve the DependencyProvider. This does not support the multi-level branching case.

Right now, we'll match a non-optional property to a contractor that returns an optional and vice-versa. This will cause a crash at run-time.

We need to make sure we track the Optionality in the property's type.

The regex should check for inheritance with ":".

There's a bunch of protocols in the project that don't inherit from AnyObject in NeedleFoundation and in generated code. However, it looks like no structs will ever conform to these protocols, so making them inherit from AnyObject might be a minor performance and code size improvement.

The task sequence produces ASTComponent which is a reference type on different threads. The DependencyGraphParser.parse method consumes these objects on a different thread. Even though the CountDownLatch used to retrieve these objects have a NSCondition lock inside, these are separate lock instances per task sequence. This read/write access to ASTComponent may not be thread-safe.

needle uses constructors inside of Components to determine parent-child relationships. However, if a parent component calls the same child constructor in more than one place, that child gets repeated and the generated code is invalid as the same path shows up twice in the body.

Measure the performance between SourceKitten early-terminating AST parsing, and regex based file scanning.

Since we currently generate a new dependency provider for each scope, for all paths of that scope, this grows exponentially. We should be able to leverage the parent scope's dependency provider to avoid this explosion of generated code.

Generally tools aren't distributed through Carthage with binaries checked into a repo. SourceKitten, for example, is distributed on Homebrew.

Since samples are no longer using Carthage, there is no more checkouts of Needle that includes the generator's executable.

Expression call types can be used to connect parent and child components. We cannot directly use property types, since a child component may be instantiated within a property but not returned as the return type.

Swift Package Manager requires the Package.swift file to be at the root of the repo, in order for other projects to pull in the project as a dependency. If we simply do that, the generated project would include Sample and Foundation code. This is required to support development of needle-extension.

Since the logic in ComponentInstantiationValidator runs on a large number of file contents with complex Regex, this can become a performance bottleneck. We should multi-thread this processor.

These are valid in general.

The following scenario would cause a runtime stack overflow crash.

public protocol CyclicPluginExtension: PluginExtension {
    var cyclicObject: Object { get }
}

public class CyclicCoreComponent<Dep, CyclicPluginExtension, CyclicNonCoreComponent> {
    var cyclicObject: Object {
        return pluginExtension.cyclicObject
    }
}

public protocol CyclicNonCoreDependency {
    var cyclicObject: Object { get }
}

public class CyclicNonCoreComponent<CyclicNonCoreDependency> {
    var cyclicObject: Object {
        return dependency.cyclicObject
    }
}

When a dependency is declared that is used by some Component in the system, it must directly inherit from NeedleFoundation.Dependency. You can't have some other dependency and then add to it by using it as a parent. Would be nice if needle looked at protocol inheritance and considered the union of all the properties.

Execution framework is not Needle specific. Move it to the Swift-Concurrency repo instead.