I have a project that contains several sub projects, one of which is a JavaScript project. I want to use the JavaScript project as a task runner for the entire project via gulp but I'm running into some trouble.
My project structure is essentially:
root
|_
js-client
|_
package.json
|_
node_modules
|_
go-server
I've determined that .yarnrc can be used to specify a different node_modules location, so I moved package.json to the root directory and created this .yarnrc file:
--modules-folder client/node_modules
Now when I run yarn install from the root directory, the modules do get installed exactly as I expect in the specified location but when I run yarn build I get this error:
[09:46:17] Local modules not found in ~/Documents/Projects/root
[09:46:17] Try running: npm install
I'm guessing this means --modules-folder is only used as a flag for install and not for run. Is what I'm trying to do possible, or do I just have to create a separate yarn project to run tasks? I'd rather not rely on global to accomplish this
The answer is to run yarn with --cwd
This changes yarn's working directory to whatever you specify
So for the example above, to run yarn build from the root directory, you would type:
yarn --cwd js-client build
Do you have a build script in your package.json?
If not, I would add it to your package.json to overwrite the default behavior and start the script with something like: cd client && yarn build.
Edit:
root
--package.json (with the build script)
--client
Related
I am developing vue project and syncing dist folder with git. This worked well while using webpack. However, I have moved to #vue/cli --- using vue create myProject instead of vue init webpack myProj.
The issue is that every time i run npm run build, it deletes dist folder and recreates it -- all .git and other files gone.
How do I prevent new build from deleting required files in dist folder and only update the changes?
Assuming you have your own mechanism for cleaning up the old resources, vue-cli-service build comes with this option called --no-clean to instruct the compiler not to remove the "dist" directory before building the project.
So, add the switch/option to the build script on package.json:
{
"scripts": {
"build": "vue-cli-service build --no-clean"
}
}
Alternatively, if you use Yarn, you can pass additional argument(s) right after the script name. So there's no need to make any change to the script. To run it:
yarn build --no-clean
Thanks to answer by Yom S. the documentation here does provide way to keep older dist.
However, the you can't use --no-clean like npm build --no-clean. To use no clean mode from terminal you need to write following command instead
./node_modules/.bin/vue-cli-service --no-clean
Update
Instead you can also add --no-clean in package.json
What i want is to have a library locally that when i change it those changes are reflected in the project that is using the library.
i have check out this library here in my local machine: https://github.com/manfredsteyer/angular-oauth2-oidc
So what i'm doing right now, is that i go to the library directory and then
npm link
And then get in my project directory and do
npm link angular-oauth2-oidc
The library folder appears inside my node_modules folder but i can't manage to use it, since when i start the app ng serve it says:
Cannot find module 'angular-oauth2-oidc'
I'm importing like this:
import { OAuthModule } from 'angular-oauth2-oidc';
I've tried to add the the path under the compilerOptions of the tsconfig.json file but haven't been sucessful.
Any ideas on what i'm missing here? I've tried several suggestions i've found on angular github issues but none solved my problem.
Thanks in advance
npm link in a package folder will create a symlink in the global folder {prefix}/lib/node_modules/ that links to the package where the npm link command was executed
Dont use npm link to add a library to your project, use npm install :
npm install angular-oauth2-oidc --save
You have to install it not just link it, so use this line to with flag --save to ensure that it will be saved in your package.json
npm install [package_name] --save
You can get the package name from the source website or from
https://www.npmjs.com/package/angular2
When you say:
So what i'm doing right now, is that i go to the library directory and
then npm link
Do you mean you are executing npm link in the folder you cloned the repository in? Because if so, that's likely your issue as that's the source directory and not what's actually published as a package. You must build the library, change directory into the distribution folder for the package, and then run npm link. Then when you run builds of that library, any Angular applications with that linked will automatically have the last version of your build in their node_modules.
Also, in your Angular applications where you are using the linked library you'll want to make sure you are setting preserveSymlinks to true in your angular.json.
While you can create multiple projects (e.g. an Angular app and an Angular library) under one Angular project to make this process a bit easier, I prefer to separating these two since I like one git repository to present one module.
First, you need to link your modules to your project's package.json file. Here's how to link files locally in general:
Local dependency in package.json
Linking a plain Typescript library is pretty straight forward as you just create an entry point (usually index.ts) file and export everything you want from there. This file needs to be in the same folder as the package.json file in your project.
An Angular library is a bit different as angular modules needs to be compiled before it can be properly exported. If you just import the module to your project without compiling you will get an error stating this: cannot read property 'ɵmod'. This happens at least at the time of writing this.
So we need to compile the library and then link it:
open two terminal windows
in the first terminal, go to your Angular library's root folder and run ng build --watch
check the output folder of the compiled module, usually something like dist/[library name]
change your Angular project's package.json to point to the output folder e.g. "my-angular-library": "file:../my-angular-library/dist/my-angular-library"
run npm install in the same folder
Add path to your Angular project's tsconfig.json e.g:
compilerOptions: {
"paths": {
"my-angular-library": ["./node_modules/my-angular-library"]
}
}
Otherwise you'll get errors like Error: Symbol MyComponent declared in /path/to/library/my.component.d.ts is not exported from my-angular-library
in the second terminal, go to your Angular project's root folder and run ng serve. Make sure you serve the project only after you have installed the local dependency.
You should now be able to use components, services etc. exported via your library module.
TL;DR
for the library ng build --watch
make the library dependency to point to the output folder e.g. "my-angular-library": "file:../my-angular-library/dist/my-angular-library"
npm i
Add path to your Angular project's tsconfig.json e.g:
compilerOptions: {
"paths": {
"my-angular-library": ["./node_modules/my-angular-library"]
}
}
ng serve
Right now I got a NodeJS backend for a system I built. The problem is that I need to also maintain another instance of the backend for some client specific requirements, both of the instances share like 70-80% of the code. At the moment I'm using git branches to keep them apart, I know git is not meant to do this, so I would like to know if there is something that allows me to have two separate projects sharing some codebase, similar to flavors in Android.
There are few options to do this:
1. Install your own module as separate dependency with npm via package.json dependency.
create own reusable code as separate project on your git space
specify it as dependency in package.json
use it by installing it with npm install, in same fashion you do with regular npm modules
2. Use docker.
Docker is container virtualisation engine, that allows you to create images of vritual environments with pre-installed infrastructure/file system
You just crete image with some linux os inside, node and your module preinstalled, and all you need is to mount your unique code as "volume" to the container and thats it.
use nodejs offcial image - it have everything basic node.js env would need - to create own image. In the folder where you have /reusable_code folder and package.json create Dockerile file
Dockerfile:
FROM node:6.9.2
RUN mkdir app
COPY ./reusable_code /app/reusable_code
COPY ./package.json /app/package.json
WORKDIR /app
RUN npm install -g <your global modules> && npm install
now run docker build -t base-image-with-reusable-code .
It will create and tag the image as base-image-with-reusable-code
Now once you want to use it with any unique code you should do from the folder where the code is (this assuming all unique code use same package.json dependencies used in previous step - if not this will need extra step)
docker run -ti -v ./app.js:/app/app.js -v ./unique_code:/app/unique_code base-image-with-reusable-code node app.js
Of course names should be corrected, and if you have different project structure then the changes should reflect that.
3. Link the reusable code module folder via OS
Simply put, just ln -s /path/to/reusable/code ./resuable_code from your unique code project root folder, and then use it assuming it residing at root of every unique project you have linked it to.
4. Link the reusable code module folder via npm link
as suggested by #Paul :
node native way to do #3 is via npm link, which both sets up the symlink and makes reference to it in your package.json so that your code can treat it as an external module
Assuming you have reusable code folder in same folder where unique code folders are located:
Modified example of the npm link docs:
cd ~/projects/unique_project1 # go into the dir of your main project
npm link ../reusable_code # link the dir of your dependency
Note : all solutions assume you have separate git project for your reusable code. Generally speaking , it's a good practice.
I am pretty new to Gulp and I've got a question: should I install gulp plugins (such as gulp-sass or gulp-imagemin) locally or globally? In examples around the web people mostly do it locally (with --save-dev option). As I understand, by doing so the modules are stored in the local node_modules folder, added in the local package.json as devDependencies and can be referenced to in the local gulpfile.js via require(). So, if I need to install the same modules for another project I work on, it may be accomplished by copying package.json to a new project's folder and typing in npm install in a command line tool (after getting to the project's folder). Fine.
But what if I, as a regular gulp user, don't have plans to upload and share my stuff on the npm space and not interested in maintaining devDependencies, can I in this case just install gulp plugins globally like npm install -g gulp-sass? Will they be found through a global path in my system? Is it an option on the whole, if I don't want to bother myself to copy package.json, run npm install every time I create a new project or have multiple copies of the same modules scattered around on my disk?
For plugins that you are using via gulp, what you have to do is install them locally to the project. Although you have to install gulp itself globally and locally, to run the file and then for the project to pick up the gulp based commands and functions.
The reason you should install the plugins via npm locally is so that it is specific to the project, for example if you then went to upload this project to your server or host on github then you would have to then go and have to globally install all of your packages again. If they are saved, they exist in your packages.json, this is so that when you go to run npm install to install all the packages for said project npm knows what to install.
If I can further clarify anything let me know.
A kind of "global install" for the typical case OP explained, could be to have a folder where you put your package.json with every dependencies you need for each of your projects, and run npm install from there.
And put here also your gulpfiles for each project (you could named them as you want), like gulpfile-project1.js, conf-project2.js... whatever.
Of course adjust your paths in those files accordingly.
And from this directory, run gulp using the -f flag:
gulp -f gulpfile-project1.js
So you end with this kind of scaffolding :
my_dev_directory
- project1
- dev
- main.less
- main.js
- www
- main.css
- main.js
- gulp
- node_modules
- package.json
- package-lock.json
- gulpfile-project1.js
In your gulpfiles, start to declare a const with the base path of your project to ease all path declarations, like:
const path_dev = '../project1/dev';
const path_www = '../project1/www';
This way you have only one node_modules directory installed on your disk and your projects directories contain only public files you want to upload, no dev files.
Of course one of the main drawback is that you share the same module version with all your projects, but it answered to OP's need and even if it's not recommended, not the "proper way to do", you are free to do as you want with your dev tools :)
I am doing an internship in a company.
I need to create a node server.
I installed node on the computer (Windows) and I should install some plugins like:
- nodejs-webpack
- colors
- uglify
Normally I need to enter a command like : npm install "theModule"
But the software can not access the internet (due to company restrictions) and support service can not authorize the software (or do not want).
Can I install modules in any other way ? (download from Google and slide archives in the correct folder for example).
If the answer is no, do you know how can i get around this security?
You need a private npm repository.
Check out this answer:
can you host a private repository for your organization to use with npm?
I found it !
Just for exemple, we will install 'nodejs-websocket' :
1) You just have to download it here.
2) Put files into your Node's directory (for me it's "C:\Program Files\nodejs\node_modules\npm\node_modules")
3) in your .js file just add this line : var ws = require("C:/Program Files/nodejs/node_modules/npm/node_modules/nodejs-websocket/")
Done ! Thanks for all :D
I added this as a comment on your own answer, but I figured I should add a real answer with a better explanation.
Normally when you run npm install package-name npm installs the package to a node_modules directory in the directory you are in at that moment. So if your app was located at C:\code\my-app then you would cd into that directory and run npm install package-name. This would create a node_modules directory at C:\code\my-app\node_modules if it didn't already exist. Then it would install package-name into that directory at C:\code\my-app\node_modules\package-name.
As long as the module is in the node_modules directory for your app, you can require the module in your code without entering a big long file path.
var ws = require('nodejs-websocket');
The place you manually installed your module is the global node_modules directory. It's where npm would install a module if you did npm install -g package-name. The global node_modules directory is added to your system path when you install npm. In other words, any modules you install in there would be accessible from the command line like any other command. For example:
npm install -g bower
That would install the "bower" package to the global npm module directory. Bower would then be accessible as a command line tool for you to use. For example:
bower install angularjs
The global directory is more for tools like that and not really for modules that you intend to use in your code. Technically you can require a module from anywhere by including the full path in the require call like you did, but the standard practice would be to place it in the node_modules directory in the root of your application, and then require it with just its name and not a full path.
Edit: Here's another tip that you might like to take advantage of as well.
When you normally install a module with npm install package-name, your application usually has a package.json file at the root of it. If it does, you can do npm install package-name --save and npm will add the package-name module to a list in your app's package.json file. Once a module is listed in your app's package.json file it's called a "dependency" of your app because it basically says your app depends on package-name.
Normally, when you have dependencies listed in package.json, you can completely delete your app's node_modules directory and then simply run npm install from within your app's root directory and npm will automatically install all dependencies it finds listed in your app's package.json file. Since your corporate firewall won't allow this automatic downloading of modules, you won't get that benefit. However it is still good practice to follow the same conventions.
A trick you can do to create your package.json file is to manually install your dependencies into your app's node_modules directory. Once you have the modules your app needs, you can instruct npm to create a package.json file for your app by simply running npm init. It will walk you through a few little prompts to fill out your package.json file with details about your app. It will then peek inside your node_modules directory to see if you've already installed any modules before having a package.json file. If it finds any, it will automatically add them to the dependencies field in the package.json file it creates :D
With a proper package.json in place you'll always have a nice tidy list of what dependencies your application needs, even if your node_modules directory gets deleted. Normally people add their app's node_modules directory to their .gitignore file, only checking in the package.json file. This way they don't store their dependencies in source control but they can still be easily installed on new machines that clone it by simply running npm install from inside the app's directory. In your case though you may want to just add node_modules to your source control since you can't let npm install dependencies automatically.