We are developing a project built with yeoman angular generator. Now appears the need of "puppetize" it for deployment.
Obviusly the machine serving client part should be provided with a compiled (minimified, optimized) version of the angular project. But I have no idea if we should store it on our bitbucket repo -for example on the master branch when tagging a new release-
I couldn't find any post about this practice and I could use some help.
There are some facts about angular minified version:
It is uglificated and minificated, so code is unreadable and hard to change.
It demands compilation with tool like gruntjs, which takes some time to build each time.
It works on server, but when you choose to deploy non minificated, revisioned version, you can have other problems during adding new versions to same repo - scripts have same name and are cached in browser and possible other problems.
You decided to deploy compiled version to a client machine.
If you are using version control like git. you can add to repo a folder with compiled version, so your repository have sources and dist in same folder. Possibly you have also backend code, sometimes in backend code you can add compiled version to host on server. It's better to have all code and builds in one repo, so you can do this with one command.
In my case, i wrote scripts in java, to copy builded folder to another folder. We use also Visual Studio for backend, so i wrote script adding new filenames to .cs file, so it can be visible by continous integration tool.
Going to a final, create new branch in git from release master branch. It is useful to have copy of your partial work.
I don't know how often you have releases, but you can solve it by having branches in git.
So your branches can look like this:
master
release1
release2
...
Assuming you are doing development on master and copying new versions to releases.
Related
I'm working on an old react project, which I need to add functionality to, but when deploying the react build on the server, it fails, claiming it cannot find several css and js files, although I published all files within the build folder. I tried different things:
First, I kept the old service-worker.js in the production folder the IIS uses, but replaced everything else.
Then, I tried also deleting the service-worker.js, since I thought it was optional, and my npm run build didn't create a service-worker.js file.
Then, I tried copying the service-worker.js file that existed on production, and manually changing it to point to my css and js files in the /static/ folder of my build folder.
All of these solutions have yielded the same result. So I have a few questions:
Is the service worker necessary? If not, could this error relate to something entirely different other than the service worker?
If it is necessary, why could my npm run build command not create the service worker with the rest of the files in the build folder?
If I do need it, how can I manually add it to a project that already exists?
If the production folder already had a service worker, and my build is not building it, I can also assume maybe my react version is newer, but I find that odd, since the computer I use is one an older employee in my company used, and I didn't manually change anything about this project.
I am learning React with my son using VS Code a and we are having a hard time properly syncing and setting up how to work with the same files on Github.
We have a repo with source files. Let's call it 1st-repo. His PC is fine as he has control of the repo (master). I would like to fork this repo (I think?) so I can have all the files and make my own changes.
I'm really not sure how to start in VS Code. DO I first do a blank app "npx create-react-app {name}" then clone? Or do I set it up through git/github in VS code.
Once there is the initial setup I would love to see how people work together.
You definitely don't want to npx create-react-app {name} as this will create a new application project.
If you are simply wanting to work on the same project at the same time then you only need to clone the Github repo to your machine.
git clone <link to repo>
Then change directory into the project and install the project's dependencies. This assumes you already have node installed on your machine.
cd <project directory>
npm install
From here you can open the project up in VSCode, make your changes, and commit & push them back to the remote repo. I suggest getting familiar with Git and the pull, commit, and push commands. Also get familiar with creating and switching between working branches.
Git cheet sheet
If you and your son are working on the same code in the same branch at the same time then merge conflicts will likely arise when either of you are pushing your changes back to the remote. Get in the habit of pulling any changes from the remote before you commit and push your changes, it's easier to resolve conflicts this way. VSCode even makes this stupid simple in the GUI.
VSCode also features a VS Code Share extension, called Live Share, that allows you to work in a shared window. You can see each other's cursors and position in the code.
Good Luck.
I am building a sample react native application. Currently i am running it using the node server.Node server is serving the js file.
You can see this in following screenshot:
I want to shift to the option2, for this, if there is any change in the js file, i need to run the curl command manually.
Is there any alternative for this?
AFAIK there's nothing in place and this is work in progress. See:
https://github.com/facebook/react-native/issues/12
We plan on putting in some sort of build step that "compiles" the JS
source directly into a resource file in the app bundle. Obviously in
production you wouldn't have a server running nearby.
There's another bit of discussion here.
At the moment I think you're stuck with the curl option.
All this does is packing all your JavaScript together and writing it into a single file.
Option 1 has a small http server running, providing the latest packed file when you request it.
Option 2 takes the file from the local disk.
You can setup a tool that looks watches your project files and repacks everything if you make changes.
You can do this by yourself, using the packaging tool shipped with react-native (react-native bundle [--minify]) and re-run it everytime things changes using gulp (and gulp-watch).
Also you can use webpack as your packaging tool and use the --watch option. (see example)
I'm using Yeoman to generate out an angular app. Once I'm happy with my app, I run grunt which creates a production-ready version of my application in a folder called /dist at the root of my project.
I've then initialised this /dist directory as a Git repository with git init and pushed the files up to Bitbucket, where they currently sit right now.
What I'm asking is do I have to compile my production-ready app with grunt every time I want to make a commit? It seems I have to. I'm thinking this setup might not be the most productive way to do this?
Am I missing something, is there an easier and more productive way to handling this?
That workflow is odd.
Only source code should be in your git repository. Not the compiled/minified files. Source code is what matters.
When you colaborate with somebody else, they should run grunt tasks on their own.
Dist package should be created before deploy to production. Or on regular basis by the continuous integration server.
I installed SQLite into my WPF project via Nuget. Then added the entire project to a remote repo. Then I cloned the project on another machine, and had a broken build.
x64\SQLite.Interop.dll was missing.
I'm puzzled why Git didn't include one file from my project. I checked the repo on BitBucket and confirmed it is not there. Git status reports nothing to commit, working directory clean
It added the x86 version, but not the x64 version, I can't imagine why.
(project)\x64\SQLite.Interop.dll Git ignored this file!
(project)\x86\SQLite.Interop.dll
You might want to check the .gitignore file at the root of the repo. If it contains for example x64, it would ignore this file.
There would be two main possibilities then:
edit this file to fit your need
or force this file to be added; ie: git add -f x64/SQLite.Interop.dll
However, committing binary files is often frowned upon. It's true in particular if you want to keep up to date with the latest package, hence if you plan to commit new versions of the dlls on a regular basis.
You might rather want to consider Nuget package restore feature. Basically the idea is that you commit a config file, and the client will automatically download the corresponding packages.