Is there a way to move `/platforms` and `/plugins` out of the Ionic project directory?

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?

  • If I just delete the .gitignore for these two folders, the main project gets huge and that’s not what we want for every new developer working on the project - we just want them to be able to track the changes to these two folders for themselves.
  • If I put both folders in their own git repo, I can’t use 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.
  • That leaves the last option, that I put /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?

1 Like

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:

  • plugins get updated and you don’t have an easy way to find out what exactly change in your project (pinning a version by default is no solution either, and many plugin have a ‘liveral’ interpretation on how to use semver)
  • 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)
  • also all commands depend on if they are used on Mac or Windows and have different results (Examples: different paths in config files because Windows uses . Mac uses /, chmod problems when you install things on Windows but use on Mac, …)
  • npm and gir (or any other source for the plugin files) can be down/broken/unreliable

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 :wink: (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.

1 Like

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 :smile:

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.

1 Like

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?

1 Like

good question :wink:

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 :wink:

2 Likes

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 :wink:

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.