I need to develop a mobile application using worklight. While i was going through few sample source code, I observed a gulpfile where they defined few Task/Watch in it. There was also a package.json where they have defined devDependencies property.
I like to know how a hybrid app project (when developed using Worklight or any other tool/framework) use the gulpfile, package.json, node.js, bowerrc. How is the controls passed across all these components when implemented for a hybrid app developmen and What will be the first point of execution in this sequence of execution workflow. As I believe wlEnvInit() inside main.js is the starting point of execution for a worklight project.
I tried google but could'nt find any explanation on the same.
The Gulp file you see is part of a default Ionic project. It handles compiling Sass files and running the bower install command to install dependancies. If you are using Sass in your project, then this would be useful to you, but it does not directly relate to MobileFirst.
As you know, when you update your common code, you need to do a build/deploy to get the code deployed to your mobile platforms. So if using Sass, then you need to remember that while the Gulp file may compile the CSS, you still need to "mfp bd" to deploy it to MF.
Does this answer your question?
Related
I currently have a React based website. I want to start on the process of converting the website to also work natively through react-native. I understand that I will need to re-build the UI for the native version.
My goal however is to leave both versions in the same node project so I dont have to update my non-view based code separately for both versions of the code base.
Is it possible to add the dependencies and files necessary for react native while not having to separate the native code out into it's own completely separate project and if so how?
Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.
Quick background: I'm a java web developer. I deploy my apps in EARs. I'm not familiar with how the build process works for the new JS frameworks like ReactJS. I have been using WebPack as a build tool but only in dev. I'm trying to keep up with the growing tech because my company is slowly adapting to it.
Question 1
How does the build process work when deploying a React app to a prod app server (or any server at that)?
I'm guessing Node will have to be installed on the app server with WebPack as a globally installed package so when the app is ready to be built, WebPack will kick off its build script in the package.json file that will create your bundle.
Question 2
If the above ^^ is somewhat correct, how do you kick off the WebPack build script?
My company uses IBM's Rational Team Concert as version control. RTC uses Ant scripts as their build so I'm guessing since we have a Spring Boot API that uses Gradle, we can tell the Ant script in RTC to run the Gradle script so the Spring API will build. Right before the Gradle build ends, Gradle can kick off the WebPack build script that will create the bundle.js. And from there you should have a full functioning frontend service just like you would when developing it.
This whole process has a been a headache to wrap my mind around and would like to get some clarification because there's only so much I can research without pulling all of my hair out. I hope I'm somewhat close to the correct way this process works.
In new version webpack (>=4) added new options mode for set environment. For get more information read this tutorial
webpack conf for production
and about deploy (ci,cd), webpack required before build, after build you don't need any js tools (SSR other case). Just create archive (project_${branch_name}.zip) and upload some store like gitlab, awsS3, etc and download when deploy.
I'm recommend don't mixing ui with backend if it possible split project other repository.
Note that RTC has multiple build definition templates. ANT is just one of them. You can also use the Maven build template, the Command Line as well if using the Jazz build engine. If its connected to Hudson/Jenkins for its build functions, you can use those as well.
I'm working on a web application that currently uses vuejs for part of its interface. The back-end is NOT in Node, so there is currently no package.json file or any tool from the typical npm stack in this repository.
We already have a bunch of non-npm dependencies that need to be installed in order to use the repository, so my coworkers aren't too open about the idea of adding another layer of complexity. I can't blame them for that, it's the reason why I use npm scripts and not even gulp in my other projects. I'm tired of spending hours learning and configuring build tools that never end up doing what I want anyway.
But since the vue-cli tool no longer includes the build command, I'm a bit stuck. Is there really no more CLI app to build vue files at all? And if so, what would be the smart way to use vue without webpack? Template strings are not maintainable at all, and <script type="text/x-template"> don't work when you want to use multiple components from multiple files in the same page.
I realize your question says 'without webpack' but you may be interested in backpack - a CLI app i came across for building Vue.js without requiring you to write any configuration code. It is basically webpack preconfigured as a minimalistic build system for Node.js. It provides two commands, dev for live reload enabled development and build for building you project.
I am new to programming and I learned how to use laravel and vuejs (which now ship together in laravel 5.3). I'm only practicing Vuejs right now, and was wondering what is so wrong with installing Vuejs using a simple src link rather than going the complex way of installing with npm and node.js, which is another learning curve for me if I have to learn it down the road anyways. Thanks for answering, I just don't understand what could be wrong with a simpler minified src link for a Vue.js installation.
If you use standalone version of Vue.js via a simple minified src link, it will come with a template compiler. The Vue component templates will be compiled in the browser environment for every user, before rendering. Therefore it will be slower compared to the runtime build option.
If you create a project using npm and vue-cli, you will get the runtime build of Vue.js, which will also package the vue app into one single app.js file, thus minimizing network requests for your production app. Your users will have a much better experience.
If you are only getting started, you can go with the simple minified src link for now. Once you get used to the framework, you can start using vue-cli.
I'm working on including Ember into an already deployed Node/Express/EJS application. I don't want to disrupt any of the existing application behavior, but instead, want build out any additional feature to the app using Ember. The server side code for these new features has already been built, and each endpoint returns the JSON format that Ember Data expects. I've been looking into Ember App Kit and Ember-cli, but I'm not sure how to include these tools into my existing directory structure, and I'm not certain if these are in face the right tools for my use case. Does anyone have any experience with this particular use case?
For example, navigating to /foo returns the existing express route that renders an ejs template, but /bar would be an Ember route that hits the api endpoint of the same name.
Use ember-cli (ember-cli.org). It's perfect for this situation as it allows you to rapidly prototype out your ember app. It even comes with an expressJS based testing suite and mocks server.
Once you are ready to incorporate it to your NodeJS, Flask, or whatever other application all static files should be available in the ember-cli dist directory.
Just don't forget to build the ember-cli project before porting via the means of ember build. After that it's just a simple matter of moving the files in the ember projects dist folder into wherever you need in your environment.
Just to embellish a bit: Ember-cli has a great work-flow for use while building your ember app. Try ember serve for a quick example. I mention this because it speaks to your question of how to incorporate this into your existing project (by project, I assume you may mean workflow). I typically will build ember projects purely using ember-cli and consider the back-end (usually a REST-API exposed via either Flask or NodeJS) a separate concern. When importing the app all I have to concern myself with is making sure my server serves the correct static dist files.
I would not recommend using the Ember App Kit (EAK) as it has been deprecated in favor of ember-cli. It really is.. much, much better.
Ok so I'm going to try to be more complete in this answer. Let's start with the isolated question - ember-cli or eak? Definitely Ember-Cli, but why?
EAK is officially heading for deprecation in favor of ember-cli.
Ember-cli produces more structured, cleaner, maintainable ember code.
Ember-cli integrates your entire ember-app workflow.
Managing all types of dependencies and assets is made simple via bower install --save and Brocfile.js edits. (See the ember-cli docus for explanation)
Now the more complicated part of the question. How do I integrate this with an existing workflow? I recently ran into this when building a webrtc-included ember app. It just so happened that this was my first real use of ember as well. So, not yet realizing the full potential of my new hammer I wrote the REST API, Backend ORM layer, the signalling service, the session cache, and built a complete CI workflow first. Then I was ready to build my ember app and ended up in your exact position.
To short circuit a long story - the lesson I learned was that I should treat my ember-cli app like a completely separate concern. What I mean here is - there's my backend (NodeJS, Apache, Nginx... whatever) and what I code here is built, tested and integrated separately. It normally even lives in its own git repository. It's a separate concern to my front end equation which typically would consist of several components itself. My I-Phone Native app would have its own workflow from build-to-test and integrate to my backend via a REST API. My Android native app another. My web app another. For all intents and purposes, in my workflow these are entirely separate workflows that only tie together when we start talking Continuous Integration.
There's a lot of arguments for why you'd want to do this. Most importantly - it scales.
The beauty of ember-cli is that it makes it fairly trivial to get a workflow for your ember app going and trivial to redeploy your app + workflow on a new box/instance. I would certainly recommend referring to the official ember-cli setup instructions but I'm going to include them here in case the URL goes bad one day:
No really, refer to the link my instructions will suck in comparison...
Deploying a new Ember App
Install NodeJS, NPM and Git (ember-cli will as a default load git going for you on new apps) on your system via sudo apt-get install nodejs and sudo apt-get install npm, sudo apt-get install git.
Note: On Ubuntu 14.04 and some other Debian systems use sudo apt-get install nodejs-legacy instead. If in doubt, use legacy. If you experience problems using the node command after install, it's definitely that you need to use nodejs-legacy. Don't bother trying to do the linking manually.
Install required node modules globally: sudo npm install -g ember-cli, sudo npm install -g bower, sudo npm install -g phantomjs
Create new ember-cli app: cd <Desired Directory>, ember new my-app-name
Now you can look at ember help to begin learning how to use ember-cli. Hint: The --dry-run flag is your friend. You'll notice that when you installed ember-cli all the scaffolding was taken care of for you. You'll see that you can add things with simple ember generate commands and they will not only create the required objects, but the test files as well. Best of all, using ember serve you can start scaffolding your app and via simple flags you can configure the test server to actually proxy and use your already-existing REST API (if you have one) or the expressJS mocks server to build a psuedo-API.
Integrating it with your larger workflow from here is a simple matter of configuring whatever tools you use (I use Jenkins and Ansible for this kind of stuff) to distribute the dist folder of ember-cli to where it should go to be served as static content (it is just a single page webapp in the end).
If you want to instead play with an existing ember-cli app that operates in an isolated workflow and already makes use of most of the goodies in order to get some familiarity - as I suspect you'll quickly realize how to fit this into whatever your current structure is - feel free to clone and play with this one here.
And so finally - to answer the more specific question of how this might fit into an existing directory structure, I would break this down into two categories. When we're talking src - I would have it in it's own "structure", separated at least by being in a separate sub-directory of its own. When we're talking built and deliverable I would include the contents of the /dist folder in whatever static web server directory you want to serve your ember app from.
EDIT: I Added some more detail - hopefully useful details below the line break. Let me know if you have more questions or if I can explain anything better.
I am facing a similar situation. I am planning to use EAK as a "prototyping tool" in a separate project folder. Then build the distribution directory from EAK using grunt dist and insert that into the assets folder of my main Node.js project.