[GitHub] [cordova-docs] dball-adashi commented on issue #961: Recommended dev tooling

[GitBox <gi...@apache.org>]

dball-adashi commented on issue #961: Recommended dev tooling
URL: https://github.com/apache/cordova-docs/issues/961#issuecomment-480016382
 
 
   From my perspective, the documentation on the Cordova site with the links to the other sites is/was sufficient.  Since this was spawned from my original issue  #960  let me provide some context.
   
   We are mostly a windows shop.  When we moved into web we continued to develop on Windows.  We got up to speed on nodejs, built some custom tooling using typescript with nodejs and settled on angular for our web clients.  The custom tooling basically creates and manages projects from templates and dependencies between those "npm projects" stored within a single git repository.   It can wholesale update all dependencies, perform dev builds, production builds, watch for changes, ...  I.e. everything I think you would need to maximize code sharing between projects and applications without dealing with symlinks and having to manually rebuild all items.  The goal we accomplished was to be able to add/modify any class in the lowest level "project/package" that was ideal for sharing between applications and have the build system see the change and automatically figure out what needs building, what broke, and automatically update the dependencies that web pack is serving live to the application under development. For an IDE, we started with WebStorm and them moved to VS code.  For running command line prompts, we started in the DOS Cmd prompt and powershell.  We later moved to git bash.  As our knowledge grew we started scripting all aspects not handled by our custom node js build system in bash so it could run on both OSX and Windows as this was required for our Cordova projects.   These scripts guarantee all global dependencies are met (both system configuration and global packages) and perform all of the steps of configuring and/or reconfiguring projects to build and validate every application we currently support and prepare them for all of our deployments.
   
   Our initial use of Cordova was used under the DOS Cmd prompt and powershell and then graduated to Git Bash (MinGW).  As far as I know all of this worked perfectly.  But of course attempting to push the boundaries of development efficiency, we are starting to reevaluate the use of VSCode.  A combination of Vim, TMUX, and some Vim plugins such as YCM are looking very tempting.  These are still under evaluation. 
   
   Where we got into trouble was when we started running cordova from within tmux within cygwin.  Tmux is not easy to add to GitBash (although) someone did identify how they did it.  We should probably look at a full MinGW install (TODO).  An evaluation of Ubuntu of WSL found that this was problematic based on its hybrid approach to using the same commands as were on the windows system.  Instead we found cygwin and it seemed to work amazingly.  Turns out it does not always work as expected.  Yesterday I spent between 1 to 3 hours trying to figure out why Cordova failed to add any plugins that were from the local file system or a git repository.  I was asking myself if it broke recently, if it was maintained, tested, ...?  I then stumbled across a link that implied it may be due to being run as a subprocess.  I tried to rerun the commands that should have originally worked before I started tweaking them back in git bash.  It worked perfectly.
   
   Btw, the responsiveness of @brodybits was amazing.
   
   I now know linux, OSX, and bash scripting reasonably well.  I could not say that when we started down this path.  In hindsight I would not favor developing these types of applications on Windows if Linux or OSX was a possibility.  But it is definitely doable on Windows.
   
   I believe I have read every page of the Cordova site over time and some pages multiple times when I came back to them.  The links to pages to understand for native development were good for anyone who would take the time to read them.
   
   At least in my case, I don't think improved documentation (as it is already good) would have avoided this issue as eventually I would probably search for a faster way to use the tools that would likely go outside of the environments you can cost effectively test.
   
   But thinking back to the beginning, a step by step walkthrough of every tool that you would recommend using on Windows from the IDE to shells may have been helpful.  And if you recommend testing any cordova failure back on this environment if there is an issue, maybe I would have remembered that and tried that initially.  My ignorance of not considering that the cordova command (or one of the commands it calls) might work differently in a different shell is what caused my issue here.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cordova.apache.org
For additional commands, e-mail: commits-help@cordova.apache.org