1) Does it clone the repo or does it pull from releases? From what I can tell it is pulling from releases.
2) Can this be overriden via options in the same way you specify #version for a specific version. ie I want to pull a specific zip from a release branch or just clone the repo
The reason I am asking is that lets take https://github.com/Dogfalo/materialize/releases look at v 0.96.0, you can see it has 4 different release zip files, how does jspm know which one to get?
I was starting to write an override for materialize and add it to the jspm registry but I ran into a problem, for me I want the whole repo as it also contains the sass files in addition to the css and js, but the way jspm current installs materialize if you use this command jspm install materialize=github:dogfalo/materialize#0.96.0 it installs materialize-v0.96.0.zip release which does not contain the sass files rather the source code zip is what I would like or a clone of the repo.
Just read on gitter that you can specify master when you install JSPM
For example:
jspm install materialize=github:Dogfalo/materialize#master
or for a registry package:
jspm install bootstrap-material#master
Related
The node module that I need has been updated, and there is an old version of it installed on the gitlab project. Is it possible to get the folder for that specific module as it is when it was installed?
Thank you
You dont't want to keep source code of external dependencies in your repo. You should add your node_modules to .gitignore and remove it from the repo. Instead, you just track your dependencies in your package.json file by installing them via npm install --save. Then, when someone checks out your project, he just runs npm install and all dependencies get resolved automatically. If you want to update any of the dependencies, you update it via npm cli, and commit the updated package.json to your repo.
I have a node package react-native-push-notification for which i have made some changes in the packages to fulfil my requirement. But every time i do a npm install the new (original package without my changes) package overlaps with my current package.
Is there any way i can restrict npm install to ignore my modified package? And also i want to push this package to git.
Any lead will be highly appreciated.
If I understand you correctly you have made some changes to the already existing node package react-native-push-notification and you would rather use your own version of it than the original.
You have a couple of options:
In package.json change react-native-push-notification to point to your git repo (e.g. your fork on github). This is not ideal since it makes semver problematic. But it works.
Rename your fork of the package and use that directly from npm. E.g. rename to react-native-push-notification2 or even better, use a scoped package name e.g. #yournick/react-native-push-notification and publish that to npm. Change your package.json to use this package instead.
Convince the authors of the original package to incorporate your changes. This is the ideal solution, but might be difficult to get your patch merged etc.
patch-package is exactly what you're looking for: https://github.com/ds300/patch-package
It will preserve your changes even after running npm install.
The best way to handle this would be to fork the repo https://help.github.com/articles/fork-a-repo/.
This way, you have control of the contents of the package.
Then update your package.json with your repo address.
I also would recommend not pushing your packages to Git. Packages are already under version control (in their own repo) and pushing to Git just bloats your repo for no reason.
Yes you can do it very easily. Fist of all go to the plugin GitHub repository then fork it to your profile. Before if you want to install this plugin from the direct repo, you have to run this command -
npm i https://github.com/zo0r/react-native-push-notification.git
But after successful fork, it will install the modified files that you have made changes and the command should be -
npm i https://github.com/YourUserName/react-native-push-notification.git
and boom your modified files never will change.
My private GitLab repository stores a NodeJs module (it contains package.json and index.js). In another project, I want to refer to this repository as a dependency using
"package-name": "git+ssh://git#gitlab01:path/to/repo#branch"
Where:
- «gitlab01» is the hostname of my companies GitLab server (resolvable in my network)
- «branch» is the branch I am pushing stuff on and is supposed to
be updateable via npm install.
Up until now, I can only update to a new version by using an additional tag in GitLab that I am using instead of branch (e.g. v0.1.3) that I have to replace in the package.json each and every time. Then I have to delete the "node_modules" folder and run npm install to do a clean update.
How can I achieve that the latest commit is being used by npm install without the need of a tag added manually every time in GitLab and changing it in the package.json?
You can use semantic versions instead branch name. To setup your "package" repo should match versions (tags) with branches, for instance:
git checkout branch100
npm version 1.0.0
git push
git checkout branch110
npm version 1.1.0
git push
...
git push --tags
Then go to your "project" and set in package.json:
"package-name": "git+ssh://git#gitlab01:path/to/repo#semver:>1.0.0"
Then:
npm install
It will install 1.1.0 version. Read carefully about semver (versions, ranges, etc)
I am just getting into the GIT / GULP / Bower workflow. I am basically a complete noob. I have a WordPresstheme being developed on my local machine via MAMP.
Say I wanted to package it up and open it on another Machine, either with Mamp or Wamp.
I don't think I can zip the theme folder with all the NPM Nodules, so what would be the best steps to take to avoid any or minimal bugs.
If you're using git you need to commit and push your changes to a remote repo. Then pull the repo down to the second machine and re-run the build process.
In roots sage 8 that will mean:
Installing bower and npm globally (if you haven't already done so)
Installing the bower npm packages for you project
Running the gulp build task
In Sage the npm modules, bower packages and dist folders are ignored by git because they are listed in .gitignore.
In general it's usually considered good practice NOT to commit any dependancies to your projects repo.
I'm evaluating JHipster; it looks great for rapid development!
Maybe a novice question: I see that the generated .gitignore ignores certain things, e.g.
/node/**
/node_modules/**
So, if I check in the generated project to a repository, and then some other developer in my team checks it out in his environment, the project would not work in his environment. Would it?
Was curious to know how to handle this. Thanks.
Since your git repo won't track node packages, others using your git repo will need install node.js, then run npm install to download all the node packages.
It's similar to them having to have java and maven installed on their environment.
Update: A developer will run 'git clone '. The source (not including node or bower) will be on their workstation. Once they've installed node.js, they'll run 'npm install' and the node directories will be created automatically for your project by downloading them from the Internet. That way you don't need to keep all your node libraries in your own git repository ...just their package name and version in the package.json file (similar to maven dependencies in pom.xml).
No one should commit the node_modules or bower_components to git, what you would do is share the project like you share the maven projects.
Write in the read me what needs to be done to get them ready, for example the installation of yo, bower, grunt or gulp and generator-jhipster.
What is very nice about liquibase, each developer can have his own version of the database, and every commit has its own database version.
What we our team does, if a developer adds something to node js package.json then we mention it in the comment: npm install needed and the same applies for bower.
That way you keep all your environments clean, and if you would like to install continuous integration like "Jenkins or Teamcity" then you make sure Jenkins is building rebuilding the whole project.