Hey, for reasons I want to get rid of /platforms
and /plugins
in my Ionic project directoy.
Is there a way to somehow tell Ionic/Cordova that these are not here but somewhere else?
Hey, for reasons I want to get rid of /platforms
and /plugins
in my Ionic project directoy.
Is there a way to somehow tell Ionic/Cordova that these are not here but somewhere else?
and what would be the advantage of that? ā¦ i think this would be nothing but confusion.
Do you really want to know it?
Well thenā¦
I need to keep track of the changes to /plugins
and /platforms
, and the easiest way to do this is to put them in a repository in git. But how do I do that?
ionic state reset
any more as it just deletes the whole /platforms
folder, and by that also deletes the .git
folder and the connection to the repo. Also some tools like ionic state restore
or ionic state save
have problems with the .git
folder in there too - restore
e.g. just stops working if it finds a .git
in /plugins
and doesnāt install the plugins after failing silently./plugins
and /platforms
in a folder and put that in git. But to do that I have to change the folder structure somehow, and thatās why I posted this question here.WHat about using symbolic links to another folder using its own repo?
Or using git sub modules?
i can not image the sense of that. --> all your added plugins and platforms are stored in config files/package.json.
This is necessary to recreate everything in the with the command āionic state resetāā¦ it is enough to see the changes of that configs, right?
Thatās a good idea. Will this work on Windows?
Never used them before. How does it work?
In theory, yes, package.json should be in enough.
But in practice there are multiple problems I encountered and spent time fixing:
ionic state restore
or ionic state reset
fail sometimes and do strange things (like not installing plugins at all or not copying framework files to where they should be)Thatās why I now think using a command to reproduce the code that was the base for an app build (especially releases in the app store) just doesnāt cut it. Release branches in git with tags solve that problem - I just have to find a way to make them work.
in case of the develop environment --> if you work with other people together you need to establish a common workflow like --> everything should be developed in a vagrant vm --> this vm is the same on the same for all like ubuntu 14.04 lts release ā¦ so you do not have to think about changing paths, file permissions. And to fix your plugin version problem --> set fixed plugin versions for a project (e.g. ionic plugin add org.apache.cordova.console**@0.2.1**).
It should be enough to know, which project uses the exactly plugin version.
But that is your businessā¦ i only can share my experiences.
Uffā¦ Vagrant for Ionic development? Sounds a bit harsh. I want to avoid that.
Yes sure, but you donāt want to pin ALL plugins, donāt you? Then updating to the newest version gets a real pain and a major process you have repeatedly to do. Or how do you manage that with pinned versions?[quote=ābengtler, post:7, topic:37976ā]
But that is your businessā¦ i only can share my experiences.
[/quote]Thatās fine and I appreciate that! Iām also open to be convinced - jsut didnāt happen yet
if you want stability --> you create software with pinned versions, because you are never safe for breaking changes.
It is up to you, how you keep your app up to date.
If you want it really extreme --> add a vagrant file to all your projects.
if you want to fix bugs in a two years old app --> you only need to call āvagrant upā and everything works like expected and you can fix the bugā¦ and after that you can try to upgrade the project ;).
Thats professional work.
Setting up vagrant is really easyā¦ there is an old vagrant machine called ionic box --> everything installed (but a little bit old). Android, Java, ionic, cordova + usb drivers installed. Upgrade all the dependencies and you have your working env.
Symbolic links (aka shortcuts) on WIndows work well but not for all. I had issues with node_modules and npm where links across disks did not work. If you stay on same disk, it should be fine.
About git sub modules, itās just a tool, itās up to you to decide how you want to use it.
@bengtler about using Vagrant, I can see the benefits and how it would work for Android but how do you do for iOS?
good question
during my experiences in different software companies is windows the prefered os (do not ask me why^^).
And i separate between development and building.
If i develop i test everything in browserā¦ after that i test the most stuff on android (it is a little bit easier because of the profile, uuid stuff on ios). Also you see it --> i am not a friend how apple provides their soft- and hardware. The usage of their services and tools for development is a mess in my eyes. Still the confusing and amount of work you have to do to get push notification to work and testing it on real conditions (different certificate versions and the whole crap) ā¦ it is so ooold school and only for doing things differentā¦ but i am getting in range mode^^
Almost at the very end the app is tested on the full device pool. For building ios we are using phonegap build if it is possible. I have written some tools to minify images, concat templates, minify and packaging javascript sources and you get a final zip at the end --> i only need to upload to phonegap or you get the final apk directly.
but i am searching for better solutions from time to time, but i did not find the holy grail, yet.
The problem is i do not want to force people to use my system configuration and so on. And to have the same development environment i am using vagrant and sometimes docker as an addition.
But i think this is the only way to keep your code base clear and avoids such thoughts to store something like plugins in own repositories. It is like using bower or npm but adding them to the own repositories.
I am also deep in backend and api development for appsā¦ so i should implement and test this part on a system it will run laterā¦ and this is in most cases a linux server.
Such idea is something like āthere are other things wrong, if i have to do itā ^^.
But how i said --> a little vagrant file (independend how you build your app) helps you to be on the correct state of your app, webapp, backend.
Easy to switch between multiple projects. You can use this also on your macā¦ and if you need to build stuff for ios --> make it outside of your vagrant vm (but there you need to check your ionic cli version and so on.)
The aim is to minify problem zones and pitfalls. Sometimes you can not avoid all, but you can prevent many
Fully agree with your approach.
Ok, I read a bit about vagrant and the ionic-box (here for example: http://digitaldrummerj.me/ionicbox-notes/).
What I didnāt know until just now, is that this box is shell only and there is no GUI involved. And I develop on my machine, not in a VirtualBox.
Now I get why this could be interesting! Consistent environment, always the right Ionic CLI or Cordova CLI version I used the last time. It even doesnāt matter if I am on Mac or Windows, as the vagrant box is always linux and behaving consistently. That I can wrap my head around, that sounds awesome.
That I still have to go āoutsideā to build on iOS is a bummer, though. I have to investigate if there is a better way for thatā¦ Maybe just open the xcode project from the āsharedā folder or something?
But @bengtler, does this help to solve my "I want to be able to see (read: diff) the changes I get by updating my plugins or recreating the platforms?
with that it is enough to know the plugin, cli versions. if everyone is using the same vagrant machine there are no differences in the plugins at all
Yes, I get that. But what if I want to upgrade or reinstall a plugin (yes this is a real need - the one why I started this thread). Nothing I overlooked that woul solve that, correct?
if you upgrade a plugin --> upgrade to a new specific version --> you will see it in the package.json afterwardsā¦ and if you know the version you can look in the original repository of the pluginā¦ if you need some diffs
I really canāt see too why doing this instead of adding to .gitignore and keep all of your configurations in package.json. I"m working in a Ionic project with another 2 developers and we are doing this. If thereās a change in a plugin version (example), the package.json keep track of it. Everytime one of the devs made a change to it, he warns the others and each one resets his own environment.
By the way, this is the same flow to other projects from other languages or frameworks: remove all dependencies from the control version and add them to a configuration file.