I am having a hard time integrating deployd into an already existing angular grunt workflow.
Did somebody ever accomplish to do this easily.
Steps taken so far:
added deployd and grunt-deployd to the proji
adjusted the gruntfile in x many ways
project has a public folder where the angularjs resides.
and the rest is the usual dpd create stuff
now dpd -d gets me to the dashboard but it collides with the grunt modules of the existing project mainly grunt-concurrent and instantly crashes dpd
if I run the proji with grunt server it does load the dashboard on port 7777 but its blank so one can not do anything the dashboard usually offers.
It further does not proxy the api endpoints properly to port 9000 it fails with cannot get.
I have seen projects on git trying to do the same but almost all of them are broken.
https://github.com/taras/grunt-deployd/issues/1
Like this guy that switched away from deployd.
I think its a pity as deployd is such a great thing. My friend said as well if the integration would be easier in situations where you do not want to do stuff with dpd-client and the dashboard white instead of black much more people would love to use it!
I would like to post my gruntfile but wanted to see first if thats useful at all.
Update:
Deployd has been updated to be able to integrate Grunt, Gulp or other dev tools with Deployd.
The documentation page for this feature is available here:
http://docs.deployd.com/docs/server/use-grunt-or-gulp.html
tldr: you just need to add a package.json with deployd in the dependencies and gulp/grunt in your devDependencies.
Old answer: Running deployd with Grunt, Gulp or any other Nodejs module is a known issue.
I proposed a pull request that fixes the problem, but more tests are needed to be accepted.
Temporarily, I use the fork of the pull request and add this repo in my package.json (here's a working example):
"dependencies": {
"deployd": "nicolasritouet/deployd"
}
Related
I've recently tried getting into the whole Node ecosystem and am trying to set up some continuous deployment for my app to AWS Amplify.
For background, my project structure looks like this:
project
public
index.html
src
App.tsx/App.js
package.json
As far as I know, this is basically what create-react-app gave me to start with, and I didn't change the file structure.
For most of my time working on the app, I've been able to go to the base project directory and use
npm start
to launch the app. This will bring me to the App.tsx/js homepage.
However, when I hosted this to AWS Amplify via GitHub, the default build settings actually point to the public directory, so the published site is actually point to index.html (which is basically just an empty placeholder).
While debugging, I ran
npm build
in my root project directory, which constructed a build folder, so now the overall project looks like this:
project
build
index.html
public
index.html
src
App.tsx/App.js
package.json
Now, running
npm start
will bring me to the index.html from the build directory, instead of App.js/tsx as it used to.
The AWS setup says that it will run
npm build
so I assume that what I've done on my local machine is mirroring what the AWS server is doing behind the scenes and explains why AWS is serving the empty index.html.
I've read a few articles and watched some videos about hosting a create-react-app on AWS, and in every version, it looks like AWS will serve the App.tsx/App.js right out of the box, rather than build/index.html, and I've not been able to find a good guide on how to configure this behavior. Quite frankly, there is an overwhelming number of similar-but-slightly-different answers for questions like this, which use different combinations of package managers, packages, hosting services, all on different release versions, with different setups, and it's very difficult for me to tell which ones apply to my scenario.
So I'm hoping someone can help straighten some of this out for me, or point me towards a good resource for learning more about this type of thing. Particularly interested in learning the right way to do these things, rather than a quick hack around whatever my particular issue is.
Some specific questions...
Is deploying things from a /build folder standard convention?
Why does create-react-app create a separate /src/app.tsx and /public/index.html that seem to be competing with one another as the app's "homepage"?
Why does the behavior of
npm start
change depending on whether
npm build
has been run?
Is the correct fix here to just insert my App.tsx component into the index.html? This doesn't seem hard, but doesn't seem right either
I have seen a lot of answers discussing tweaks to webpack.config.js to solve issues like this one. My project does have webpack installed, but as best I can tell, there is no webpack.config.js anywhere. Am I expected to create this file, or should it exist already? In either case, in which directory is it supposed to live? I've seen a couple answers saying it should be in /node_modules/webpack/, but also some saying it needs to live in the same directory as package.json
Things I've tried already: Spent a bunch of time reading through other StackOverflows and watching a few videos, but as outlined above, I'm finding it difficult to tell which could apply to my situation and which are unrelated, given the huge number of unique combinations of build/packages/platforms/versions. Also spent some time monkeying around with file structure/moving code around, but not very productively.
Eventually found my issue. In the production built version of my app (aka, /build), the bundled script created by webpack was failing in the browser because exports was undefined, so index.html was being served in its vanilla state, rather than with the TSX/JSX content. I changed the "module" property in tsconfig.json from commonjs to es6 and this fixed most of the problems.
Also of note is that the reason I couldn't find my webpack.config.js is that I had hidden ALL js files in my project, so VSCode wasn't finding it. I swapped to the suggestion from this blogpost to hide only js files with a matching TS file.
For general learning about how create-react-app works, I eventually found this page, which I found helpful:
https://blog.logrocket.com/getting-started-with-create-react-app-d93147444a27/
For the basic create-react-app
npm start
Is a short command for react-scripts start that sets up the development environment and starts your development server usually localhost:3000
npm build
After you are done developing, this command short for react-scripts build correctly bundles your app for production and optimizes the build for the best performance.
The files generated in the build folder are solely the files you serve to the public folder accessible by the public URL.
In short the files in the build folder should be copied to the public folder
AWS Amplify
Provides a CI/CD process where you don't have to set all this up by yourself, as long as you have a well-configured package.json file.
There are so many methods to deploy your react app to a production server but using AWS Amplify this link might help you out: https://youtu.be/kKwyKQ8Jxd8
More on create-react-app deployment: https://create-react-app.dev/docs/deployment/
I´m pretty new to gradle and currently there is question that bugs me. The situation appears as follows: Based on a bower technology stack I implemented an Angular App. The app as it is doesn't change nor has it to be built in any way since there are just static javascript and HTML pages. In my opinion the used versions of angular, bootstrap and other libraries should also stay the same due to compatibility of the single libraries so these files also shouldn't change. Is this a correct behavior or should I get at least the latest build of the used libraries version as I deploy the application?
Also less is used in the application. Is there a way to compile the CSS every time I run the gradle build file or should I deliver just the compiled and finished CSS file?
As a result I´m also not quite sure if it's recommended at all using gradle to deploy an "static" angular application.
I hope someone out there can help me to answer the questions above. As you can guess, I´m not very experienced at deploying of such angular applications since this is my first project with this kind of problem.
This goes for all package managers, not just gradle but npm, gem, nuget, maven, whatever.
Use static dependancy version numbers. Otherwise you will end up finding breaking dependencies in QA or Prod rather than production.
This means you need to be aware of security fixes in your dependencies.
When you need a feature or fix in a new version of your dependencies, unlock the versions, rebuild and test in dev. Re-lock the dependencies and send to QA for verification.
I am using the React Redux Starter Kit from DaveZuko, and am stuck on how to create production server to serve the compile client side code.Ideally I would just like to use the Koa server and move it to production, but can't find out how to do that.
All relevant code is unchanged from the repository here: https://github.com/davezuko/react-redux-starter-kit
Does anybody know how to compile a product server for this?
I did try to use davezuko's starter kit, but it was really hard to follow what those configuration files really did and messed them up when trying to install packages that were missing.
I also tried facebook's create-react-app, but that was really complex too when you run the eject command, so I gave up and created my own starter kit http://redux-minimal.js.org/ . I has the minimum amount of packages that lets you build rich real-word apps, but doesn't have the cluttered configuration boilerplate that other starter kits have.
Now, answering your question, with redux minimal, you just do "npm run build-prod" and it compiles the css and js files for the production environment, minified and ready to go. Then you just copy the public folder which contains the html file too, paste to what ever server you want, and then call the index.html url and it works.
i have some angularjs file that has RESTAPI access to a third party service.
say, i have multiple java applications that need to use the same angularjs file.
what is the best way to share the file.
basically, in the olden days (i am talking about back end code), we would write an application that is deployed as a service and all other applications use this service. how do i achieve this with angular.. please keep in mind, i was mostly a back end developer and entering the new front end world
thanks
I would recommend to use Bower for maintaining your reusable components. Develop standalone functionality in their own modules, doesn't matter whether they're directives, services or whatever Angular components, and then install them as Bower dependencies into any of your separate Angular applications.
Bower has documentation on creating packages, and Brian Ford has written a nice (albeit a bit outdated at places) tutorial on writing reusable Angular components using Bower.
So, basically your workflow would go like this:
Start developing your module. If it is something already existing, you can just pull it out of the current place.
mkdir your-component-name
cd your-component-name
$editor your-module.js
Once you have your-module.js started (no need to finish development first, it's actually even better not to, if you're developing a completely new component), it's time to initialize your Bower component.
bower init
You will be asked for some initial settings, like component name (defaults to the directory name, e.g. your-component-name), initial version number, main file (should most likely be your-module.js) etc. For most of the cases the default value is just fine. After bower init has been successfully run, you will have bower.json that might look somewhat like this:
{
"name": "your-component-name",
"version": "0.0.0",
"main": 'your-module.js',
"license": "MIT",
"ignore": [
"**/.*",
"node_modules",
"bower_components",
"test",
"tests"
]
}
And of course you could do all this manually, but it's nice to use the bower init helper tool.
Continue development. If you have any external dependencies, you can add them also with Bower:
bower install external-dependency --save
Finished with development? It's time to publish your component so that it can be used in your applications. If you haven't already initialized your Git repository, start with it:
git init .
Add your work, commit and tag it:
git add <your-component-contents>
git commit -m "v0.0.0"
git tag v0.0.0
This is the part, in addition to the value of version property in your bower.json (note: Brian Ford's tutorial is talking about component.json - that is unfortunately outdated stuff), where you will be able to maintain your component pretty easily within all your applications. Need a change? Just do it, bump up the version number, commit, tag and run bower update where needed.
Next step is to publish your code into a Git repository, for example GitHub
git remote add origin git#github.com:your-github-user-name/angular-your-component-name.git
git push -u origin master
Then the component can be installed:
bower install your-github-user-name/angular-your-component-name
The component can even be installed from a private repo, for example if you do not want to publish the component outside your company (see under heading "Bower Package Stewardship" in Brian Ford's tutorial for more details):
bower install git#github.com:your-github-user-name/angular-your-component-name.git
# or from any other arbitrary git repo
On the other hand, if you do wish to publish your newly created component, you should think about registering it:
bower register angular-your-component-name git#github.com:your-github-user-name/angular-your-component-name.git
So it could be searched for, and would be easier to install:
bower install angular-your-component-name
Start using your component(s) in your Angular applications. And whenever you notice a bug/missing feature with one of your apps, you can fix your component, do a new version release, and then update your applications one by one.
And then there also is npm that you could use instead of Bower. The workflow is again pretty much the same, of course differing from the tool specific parts, but otherwise no big differences. I won't go into npm packaging details now, though, just thought to mention also that as an alternative tool.
SOLUTION 1 :
This can be acheive exactly the way you described.
Deploy a Service AngularJS app (that has all your services)
for example : tomcat7/www/myServiceApp
All your needed shared will be therefore into myServiceApp/js/myShareService.js
On your apps that need to access to it, your can reference all JS files (and others) like that <script src="../myServiceApp/js/myShareService.js"></script>
Of course with that solution, both services shall be deployed on same WebServer
Solution 2:
I personnaly prefer this solution with involves Continuous integration.
I copy all shared resources on the first step of the continuous integration to my app dir so every app is independent.
In Angular we separate our app by modules which is equivalent to a package in Java. Let's say you wanted to create a package which you can re-use for other Angular JS apps.
Sample
External Package
angular.module('my-awesome-app', [])
.service('FooService', function () {
// Awesome code(s) here
});
App Package
angular.module('another-app', ['my-awesome-app'])
.controller('AppController', function (FooService) {
// Awesome code(s) here
});
instead of using import we set my-awesome-app as a dependency for another-app (which why we put it on the array) so you can call its service.
Create JS file containing Angular Module which in turn contains Factory to expose API. Minify your file and use it either thru URL or direct inclusion into your project.
I have a basic Angular app installed using a Yeoman fullstack installer, and I can see the basic pages running on http://localhost:9000 when I run 'grunt serve'.
I also have a Vagrant installation running using the ubuntu/trusty64 box. I was originally seeing a 404 when trying to view http://127.0.0.1:4567/, but following some instructions I found online, I edited the file in 'vagrant ssh' at /etc/apache2/sites-enabled/000-default.conf by removing the html part of the path in that file. After doing 'vagrant reload' I now see the list of files in my project dir when I go to that URL.
How do I go about viewing my angular app like it is at localhost:9000? If I get this working will this mean that if I share via Vagrant, they'll see the angular app running as it should? Do I still need to be running grunt serve in combination with Vagrant?
I'm pretty new to all this setup, so I'm just following the instructions at https://github.com/DaftMonk/generator-angular-fullstack & https://docs.vagrantup.com/v2/getting-started/index.html
I'm not great with Linux/cmd line stuff as yet, hence my problems... :)
Thanks!
I started writing instructions for you on how to get it done. But then realised that you are not very comfortable with linux commands. I have created a angular-seed project that uses vagrant, angular and requirejs. Its easy to set up and I have written instructions on how to do that in my github page.
Just clone it, follow the instruction and you will have a working seed project in no time. Some of the features of the seed are:
Uses vagrant and puppet to provision the vm. All required dependencies are automatically installed.
Grunt tasks for:
autoloading bower dependencies
compile sass or scss
livereload
server for access of site locally
If you have any difficulties or questions, feel free to contact me.