maintaining different package.json and config giles for dev and prod - node.js

I have a production branch and a development branch on git.
When merging changes from development branch to production, I would like to ensure that my package.json and gulpfile.js do not get merged in the changes.
How can I prevent this from happening? For deployment sake, I want to preserve productions package.json and gullpfile.js as being untouched with any possible changes to developments package and gulpfile

You can use Git attributes to tell Git to use different merge strategies for specific files in your project. One very useful option is to tell Git to not try to merge specific files when they have conflicts, but rather to use your side of the merge over someone else’s.
Full article : http://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Merge-Strategies

I believe the best practice would be to save all files in both branches, then define in the deployment process which file should be copied to root (this file will be the one used).
In my opinion it is confusing to maintain many files per branch (especially when working with git flow).
If you want it even "cleaner", in my opinion (and I think it cover most scenarios, but it might not fit your needs), you should have only one gulpfile.js, as well as package.json and an additional config file that manages the differences (this file can be copied on deployment, or you can choose which config to use by env variable).

Related

Share and manage rc files (or config files) between mltiple projects

I'm working on different projects based on node, and one thing I always have to do is create the configuration files in all the projects since you all share a lot of configuration, for example, in all projects I use commitlint, lint-stage, husky, eslint, nodemon, and typescript and other settings.
How could I share all these settings in all projects and if I update any of them, update them in all projects?
The first thing that occurs to me is to create a npm packet with all the configurations, and several scripts, that copies / updates these configuration files in the root directory of the project where user is, something like
> myscript update
> myscrpt init
Another option would be to use the configurations programmatically, that is, instead of using a .rc use a .js, but this would force me to manage the dependencies in each project and create a .rc file that uses the configuration of the js file which is in the configuration package.
Another option is to create a github repository as a template, but if I update this repository, the projects I have created using this template are not updated, right?
What do you think is the best way to do it?
Even though git submodules seem to be discouraged lately, I think it's the most reasonable choice (assuming all of your projects are git-based): https://git-scm.com/book/en/v2/Git-Tools-Submodules
In your case, you'd have a 'common' repository with configuration, eg. configuration and two projects: projectA and projectB. Both of them would have the submodules added:
git submodule add <your_git_repo_server>/configuration
Please notice, however, that submodule refers to a particular commit (not a branch or tag - commit). You always have to take big care of synchronizing your dependencies correctly.

Share one file across multiple git repo to be updated by multiple users

I am working on automating the markdown spell check for all the documents on my website which involves multiple git repo. I have a .spelling file that contains all the word to be excluded from the documents. I would like to keep it one file and updated across the entire website. I can get it to work for one repo. I looked into the npm package method. Is there a way to configure package.json to share this file to many repo? Or is there a better way to do it without npm? Thanks!
Make a separate spell-check repository with the .spelling file and script in it, then include it as a submodule in each of your docs repos. You can then reference it from each repository separately, and pull its latest updates into each one.
This could be cumbersome if you have a large number of docs repos, so another alternative is to centralize the spelling check script by making a separate repository for it and adding a configuration file to tell your script which Github repositories to spellcheck. This way, you can selectively apply the spell check process to any number of repositories in your organization.

How to update repository with built project?

I’m trying to set up GitLab CI/CD for an old client-side project that makes use of Grunt (https://github.com/yeoman/generator-angular).
Up to now the deployment worked like this:
run ’$ grunt build’ locally which built the project and created files in a ‘dist’ folder in the root of the project
commit changes
changes pulled onto production server
After creating the .gitlab-ci.yml and making a commit, the GitLab CI/CD job passes but the files in the ‘dist’ folder in the repository are not updated. If I define an artifact, I will get the changed files in the download. However I would prefer the files in ‘dist’ folder in the to be updated so we can carry on with the same workflow which suits us. Is this achievable?
I don't think commiting into your repo inside a pipeline is a good idea. Version control wouldn't be as clear, some people have automatic pipeline trigger when their repo is pushed, that'd trigger a loop of pipelines.
Instead, you might reorganize your environment to use Docker, there are numerous reasons for using Docker in a professional and development environments. To name just a few: that'd enable you to save the freshly built project into a registry and reuse it whenever needed right with the version you require and with the desired /dist inside. So that you can easily run it in multiple places, scale it, manage it etc.
If you changed to Docker you wouldn't actually have to do a thing in order to have the dist persistent, just push the image to the registry after the build is done.
But to actually answer your question:
There is a feature request hanging for a very long time for the same problem you asked about: here. Currently there is no safe and professional way to do it as GitLab members state. Although you can push back changes as one of the GitLab members suggested (Kamil Trzciński):
git push http://gitlab.com/group/project.git HEAD:my-branch
Just put it in your script section inside gitlab-ci file.
There are more hack'y methods presented there, but be sure to acknowledge risks that come with them (pipelines are more error prone and if configured in a wrong way, they might for example publish some confidential information and trigger an infinite pipelines loop to name a few).
I hope you found this useful.

Gitlab repository vs project vs submodule

I started exploring Gitlab for version control management and I got an issue at the first step itsself. When ever I create a project its creating a new repository. I have few webapplications which are independent to each other. In that case do I need to use different repository for every project.
What I am looking for is what is what and when to use what but not able to find what is repository and what is project in gitlab website as well as through other sources as well.
Also I came across a term submodule, when can it be used. Can I create one global project and have all the webapplications as different submodules.
Can any one please help me in understanding the difference between those 3 and when to use what based on their intended way of usage. Also please help me by pointing to a good learning site where I can get the information of doing basic version control operations in gitlab.
Thanks.
Gitlab manages projects: a project has many features in addition of the Git repo it includes:
issues: powerful, but lightweight issue tracking system.
merge requests: you can review and discuss code before it is merged in the branch of your code.
wiki: separate system for documentation, built right into GitLab
snippets: Snippets are little bits of code or text.
So fear each repo you create, you get additional features in its associated project.
And you can manage users associated to that project.
See GitLab documentation for more.
The Git repo and Git submodule are pure Git notions.
In your case, a submodule might not be needed, unless you want a convenient way to remember the exact versions of different webapp repo, recorded in one parent repo.
But if that is the case, then yes, you can create one global project and have all the webapplications as different submodules.
Each of those submodules would have their own GitLab project (and Git repo).

Update Gruntfile.js and Package.json across multiple projects

I am new to the world of grunt but I feel like there must be a way to do this. Hopefully I can explain my issue in a way that makes sense so you can be of assistance.
Essentially, I have a git project, including a gruntfile, that I use to start all new websites. I clone the project, delete the .git folder and setup a new project in bitbucket for it. Over time I have had to make some modifications to the gruntfile and it is annoying to go back to an old project where I hadn't made those modifications. Is there a recommended way to ensure that my template is up to date on all of my projects?
Things to note:
1) I am familiar with grunt scaffolding but I have never used it, is this the use case for it?
2) my projects live in bitbucket and are private. My initial solution to this problem was to use grunt curl and pull the latest and overwrite the previous gruntfile
3) The issue with #2 is that I would need to put my username/password in the path and can't figure out how to prompt the user, even if I do and they enter the login incorrectly bitbucket still returns something (a bad login page) and this would overwrite my gruntfile.
Thanks in advance! I appreciate anyones input
I assume you are using git with bitbucket. If that is the case you can do a pull from a master repo that contains your template grunt file in each of your project repositories for the desired effect.
See this answer for how to pull from a remote repo.
remote repo q
Since you only care about merging in changes from the Gruntfile.js you can pull it specifically from the remote template repo. I'd suggest following this pattern assuming you add the remote reference to you template repo when necessary:
From you project repo create a new branch
Pull the Gruntfile.js from the template repo
Resolve any merge conflicts
Merge with master
See the last answer on this question for how to pull a single file:
fetch a single file

Resources