I currently have two existing projects, one Node.js and one React. Both in their own folders with their own package.json and node_modules.
I wanted to create a third folder for Electron and bundle the existing projects together. Is this possible or do I need to merge all three projects together and use a single package.json and node_modules?
From my own experience with similar tasks: I'd find a good boilerplate project for that setup, clone the repo and install it. Then I'd study how they did it on the boilerplate and try to structure my own code in a similar way.
The reason for me doing it like that: the boilerplate guys are the true experts and I'm not. They know what they're doing and so their result would be good for me too.
A good candidate would be electron-react-boilerplate.
Related
I am currently working on a workspace with 2 projects. One project does not depend on the other. They are separate entities.
However a previous developer has implemented new features on the one project and I now need to implement the same features on the other project.
However the classes that he has implemented in the one project import other classes. These classes are not currently in the project I am working on.
What is the best way to share these classes across the 2 projects. I don't really want to copy the files over because that would making supporting the 2 projects harder. I.e - We would have to update both projects at the same time and is much more prone to a mistake.
Also when you do copy files from one project to the other (clicking copy) I am having a lot of issues with my project conflicting with the other project. Here is a question I asked about this issue: Xcode: Copy files from one Project to another in same workspace
Is there an elegant way to share these files across the two projects?
Thanks in advance.
If you work with Git, take a look on submodule
I am looking for the best way to share a "common" Xcode project amongst multiple developers on multiple apps. One developer will be working on the "common" Xcode project, while another developer will be working on a project that will use the source from the common code Xcode project.
Where I am stuck is how to set this up with both Xcode and Git so that when the developer of the common code library makes a change, the developer that uses that library will not have delete and re-add the Xcode project, or lose their work.
I have looked at some documentation with Git submodules, but there is a lot of debate around the topic and its usefulness. Are we better off just having one Repository with ALL the code for all the projects in it, that way everyone checks-in/out of the same place?
Thanks for the advice and pointers!
There is no "best-way" in software development. There are always a number of solutions to any problem. The trick is working out which solution best fits you. Int his case there are a number of factors to consider - how your developers like to work, what sort of experience and back grounds they have, how you want to manage the code, etc.
I think there are a few solutions you need to consider. Pick one and try it out, but don't be afraid to change if you find it doesn't work or hack it around to suite your needs.
One repo. Not usually considered the best solution because it restricts the ability to reuse code on other projects. In XCode you tend to end up with numerous build targets and highly complex builds. This can become un-manageable quite quickly. Also tends to make versioning difficult and can break things quite fast.
Multiple repos and static libraries. There are a number of variations on this. The repos can be managed by Git independently or you can employ submodules. I would seriously consider breaking code out into projects that build static libraries. Using XCode workspaces you can have a number of projects open at the same time and arrange them as either siblings or nested child projects. This depends greatly on what and how you want to build them. Using Git submodules has the advantage that the submodules are effectively versioned which means that make changes to a static library project is not going to break everything that is using. The downside of using Git submodules is that they (IMHO) are not the most user friendly part of Git and take some getting used to. A good Git client is most useful in this. Sourcetree is free, but (again IMHO) Tower is easier to use and handles submodules better than Sourcetree.
Using Cocoapods. Cocoapods is like using Maven or Ant for Xcode. It an makes things quick and easy to get running and automatically handles dependencies. However it also messes with the XCode project files, often requires manual intervention, adds additional compilations that you may not require and depending on how you setup your builds, can get in the way. Figuring out how to control the way it plays with your project files can also take some time. A lot of people like Cocoapods because it's initially easy to use and doesn't require the technical knowledge that Git Submodules require. Personally I'm not sure that bringing Java dependency management ideas into Xcode is a good idea in the long run.
The way we share common projects/libraries is through the use of private Cocoapods. Its not pure git, but cocoapods do use git. You can read the official documentation on how to set up a private podspec repo : http://guides.cocoapods.org/making/private-cocoapods.html
There are also loads of possibly simpler explanations on how to set up a private podspec repo like this one
xcode project under version control. multiple developers work on it. when adding 3rd party frameworks i prefere to keep them outside the git repo.
so whats the best practice when it comes to adding a framework (i.e. facebookSDK) to the project?
currently frameworks are "referenced". this way i have a relative path pointing outside my git repo in project.pbxproj...fail.
pretty confident that the answer is straight forward/simple and actually easy to find in the web, but it seems like i'm asking google the wrong questions...
thx.
AFAIK, there are basically two ways to be absolutely sure that a given commit uses a known version of a framework.
Commit the built framework into your repository. This is the common approach.
Use submodules to reference a repository that houses builds of the framework. You'll probably have to create and maintain such a repository yourself.
Option 2 has the benefit of keeping your repository small, but is more hassle, particularly since submodules are something of a pain to work with.
I have an app that I've been using to develop some ideas that now seem to belong into a reusable framework (a lib). The whole thing is in a local git repo. I've lots of classes that belong to a lib and a some other classes that use them and present views for testing.
I want to move out the test code and leave a library and a separate app for testing. Have you done this? Do you have stumbled into something specific? Any advise?
Of course I could just move everything piecewise into different projects but I'd like to evolve the thing so I don't lose my GIT history and everything is seamless..
If you are going to develop libraries, use submodules or subtrees. Subtrees is a contribution project to git. Submodules come with it out of the box. Check http://progit.org/book for more info on submodules.
I have an app, it's currently in the app store.
I have an idea for another app, that would share a lot of the same structure as my published app. They're both photo manipulation apps, so the codebase for importing, sharing, saving, rotating, etc. would all be shared between the two. The type of photo manipulation would be different, though.
My thinking is, when I update app #1, I want those changes in app #2, and vice versa.
What is the best way to achieve two apps from one codebase?
Strategies I've contemplated,
One project file, two targets. That way the codebase for both apps will always be up to date, though the project file/directory will be a little messy, to be sure.
Branch the app in git, frequently merge changes between the two branches for the classes used by both.
I'm open to other ideas, too.
I've found people discussing this, but mostly in relation to minor changes... i.e. one app with a few different brandings / data files. My two apps will be reasonably distinct, so I don't think those techniques necessarily apply.
Create a static library with your common photo manipulation or other shared functions, and rework the existing project to add the library as a dependency and use the library's headers folder in the User Header Search Path. Then you can essentially clone your old project and start modifying straight away with access to all of the shared library functions.
Two targets of the same project seems applicable to your situation, though. If you've got a large amount of overlap then you just basically need to write a second UI / workflow for that, right? If yes, using two targets makes a lot of sense.
I suggest split your existing app into TWO parts. Separate out all the common portions as a generic DLL/class library, and use the dll in both your existing and new project.
As the first project development progresses, use the latest version of the dll in your newer project, using appropriate deploy scripts. This way your new project can even be in a seperate codebase
I would suggest you take a look at using git submodules in both your apps. This have worked perfectly for us when sharing code in multiple apps. Basicly we use a structure where we in each Xcode project have a "Components/" folder where we keep submodules.
App A can have the submodules like this:
Components/SomeAmazingPhotoManipulationStuff
Components/MaybeSomeUsefullFoundationThingsYouUseOften
App B might only use:
Components/MaybeSomeUsefullFoundationThingsYouUseOften
The idea here is that you can update your submodule projects seperately and just go into each App where it is used and update submodule to the latest version of the component, successfully sharing stuff between apps without losing version control. It will also scale well to many projects.
And ofcourse you can branch your submodules and have App A use one branch and App B another, if you do some specific stuff or very experimental stuff in one app only or whatever scenario you might think of.
Ever since we started using git submodules like this we have not looked back or even considered any other solution.