I have a private library module mylib and an app that uses the library myapp.
When I deploy myapp, I have to include mylib in the node_modules folder so it gets uploaded as well.
But each time I make changes to mylib, I have to go to myapp and run npm install ~/mypath/mylib, which takes so much time, is there a faster way of dealing with private modules?
I think you might use some of CI services. E.g. http://jenkins-ci.org/ .
And you'll be able to set up necessary operations to run on your server after every push to your working git branch (or after private module modification).
Can't you create a symlink in your application folder to your own lib?
I know this works:
Have a root folder (f.ex. "application")
Have a "lib" folder in the root folder
Have a filesystem link to your private library in that lib folder
The downside is, that you can't access your library without a path, you need to give the path like f.ex. "require('../lib/mylib/xy')", but maybe you find this worth it.
Related
I want to do something like this, where, I want to keep all my packages globally just like node package itself. So for example in my package.json I have a package name called "Highcharts" I want to install it globally I don't want to create a local node_modules folder and use it but I want to access it from outside so next time whenever I want to create a copy of my project folder I should be able to use highcharts directly without using npm install. Is it possible?
globally installed node_modules - > Users/user/AppData/Roaming/node_modules/highcharts
app
src
node_modules (I don't want to keep it)
package.json
tsconfig.json
angular.json
How to link these globally installed node_modules with the current app or any app which we want to create?
Any help will be appreciated. Thank you so much :)
local packages are installed in the project directory
global packages are installed in a single place in your system
Usually it is a good idea to have all npm packages required for your project installed locally (project folder). This makes sure, that you can have dozens of applications which are running a different versions of each package if needed.
export NODE_PATH='yourdir'/node_modules
Hello, if am getting right, you want to keep all dependencies global.
You can just run install with -g command. Those libraries will be available in node installation folder.
From the Node docs
If the NODE_PATH environment variable is set to a colon-delimited list of absolute paths, then node will search those paths for modules if they are not found elsewhere. (Note: On Windows, NODE_PATH is delimited by semicolons instead of colons.)
Additionally, node will search in the following locations:
1: $HOME/.node_modules
2: $HOME/.node_libraries
3: $PREFIX/lib/node
Where $HOME is the user's home directory, and $PREFIX is node's configured node_prefix.
These are mostly for historic reasons. You are highly encouraged to place your dependencies locally in node_modules folders. They will be loaded faster, and more reliably.
I hope I answered, you just need to manage the paths to node_modules wherever you have kept it.
To be clear, I am not asking if I need node_modules folder on live host server. That question & answer exists on Stack Overflow already. The consensus answer, in general is YES - I still need the node_modules directory during runtime.
I am also not asking about running npm init or npm install. I understand how that works.
I am specifically asking - do I still need the node_modules directory on the live/host server if I use webpack during my build process? Doesn't webpack bundle all the necessary JS, etc into folder? Can I delete the node_modules folder if use webpack? Or, will I still need that directory during runtime?
This is for a basic front end, client side web application only. This front end calls other API only for backend sevice. This front end web application is being hosted on Windows/IIS.
The site's published code includes static references like this:
<link rel="stylesheet" href="/css/app.css?id=f243e9c6546d420fec1f">
<script src="/js/app.js?id=bf7be8f179cc272c0190"></script>
Ignore the id= part, as I think that's part of the web framework for cache busting.
No, everything is in the bundle after you build. You can take the files defined as output (usually whatever is in the "dist" folder) and stick them on whatever static server you want without the need of the supporting node_modules.
During your web pack build process ,need the node modules folder , because when you import a file from the node_modules , web pack will try to fetch the file from the particular node_module folder recursively.
Once you successfully done with the build you will get a dist package folder with all the bundles for the deployment, it will not contain node_modules folders.
You can test it by using
npm run build
Hello stakOverFlowers :D
I have a simple NodeJS WebApp that use Lerna to manage the project. So i have a package directory that contains n different projects each ones using different tasks runner tools.
I always use Maven Build Profile in java environment but for this NodeJS project maven will not be used.
So the question is...
Is there a way to reproduce the Maven Build Profile concept without using MVN?
In a nutshell i need to use a build profile in nodejs, without using MVN, to customize build for different environments such as Production v/s Development environments.
There's a way to do that?
thanks to all
you can do it by storing your configurations in a JSON file as key value pairs in the same way as you do in properties file in Java.
Then by someway or other invoke properties from the environment specific configuration file such as production.json or stage.json or qa.json.
One of the easy ways to do this is using this module named config
Using this you can pass NODE_ENV=production(or dev or qa whatever) and access relevant configurations. This will help you achieve environment profiling.
You can also store configurations in a JS file but I personally prefer a JSON file for storing configurations.
But if you're wondering for dependencies management that is done by package.json file which is somewhat similar to your pom.xml file.
For more details about it you might want to read this official documentation for it.
My solution, following the TGW advice, works!!
Just install the config module, and create a directory that containing .json files.
$ npm install config
$ mkdir config
$ vi config/default.json
Than if u are on a windows machine, choose your NODE_ENV using NODE_ENV=production and than execute your web app.
In your .js file put informations like yours dbConnection host and password.... and to retrieve it use:
var config = require('config');
var dbConfig = config.get('JsonItem.dbConfig');
..more details on https://github.com/lorenwest/node-config
I have a folder structure for a Node.js /w Angular.js project with some files like so (from project root):
frontend
frontend-file1.ts
frontend-file2.ts
backend
backend-file1.ts
backend-file2.ts
I use a TypeScript compiler along with many other gulp plugins to compile this into a build folder like so (notice how frontend files get placed into public):
build
backend-file1.js
backend-file2.js
public
frontend-file1.js
frontend-file2.js
In the source folders, I use ES6/TypeScript import statements to import files.
Example: backend-file1.ts
import './backend-file2';
Situation
I've written some custom utility functions that should be used by both backend and frontend. I don't want to repeat the same functions in both folders, since this is prone to errors and is double work.
I've considered creating a shared folder at the project root amongs the frontend and backend folders, but I can't import files in the browser that go up further than the index.html file, which is in the frontend folder.
Question
How would I be able to write a TypeScript file once and be able to import this file in both frontend and backend folders?
I would just structure the code like this:
- src/
- server/
- client/
- shared/
You can place all your shared libraries into shared directory then import/require them from your server or client source files:
import '../shared/library'
To extend the already given answer for outFile case I will show my way of dealing with class sharing in case when you cant or do not want to use webpack/browserify/outFile options.
The structure looks similar
-client
index.html
app.ts
-server
service.ts
-common
helper.ts
-dist
-client
-index.html
-lib
-client
app.js
-common
helper.js
-server
service.js
-common
helper.js
The idea is how you build the dist folder with the results of your build. I do this with gulp tasks and by having the structure above it allows me to reuse components both server and client side from the common library.
Note. To work at client side do not forget to setup base url for systemjs in index.html:
System.config({
baseURL: './lib'
});
System.defaultJSExtensions = true;
Hope this helps.
I wanted to share what I've done so that others have the same option. I felt the other options which are cleaner required a lot more work, and since this is a personal project I set it up in a simpler but more crude way.
Basically I wanted to use symlinks so that I could edit it from either location without issue and without making too many changes to the current project structure. I'm also lucky that I don't need to support Windows for this.
I already had a single repo with a React app in the fe folder and the backend server in be, both using TypeScript. Here's my resulting folder setup:
be/
src/
shared -> ../../fe/src/shared
fe/
src/
shared/
I'll note that React does not support symlinks (IIRC it's because webpack does not support symlinks) and so the "real" folder should be in the frontend.
I also wanted this to work without manual setup, and so I made an extra script in package.json which makes sure the symlink is already set up. It also creates a broken symlink if the symlink is already there, but again, this is for a personal project and I'm okay with it. (Happy to update it if someone has a better understanding of ln than I do.) In the backend's package.json:
"prebuild": "ln -f -s ../../fe/src/shared src/shared",
"build": "tsc",
I am new to JavaScript development and could do with some advice regarding how best to work with multiple modules of my own creation.
Module1
--src
----a.js
----b.js
Module2
--src
----c.js
----d.js
Module3
--src
----e.js
----f.js
Module4
--src
----g.js
----h.js
Now each module is a collection of js files that use module.exports to export functions that they need to.
In this example Module1 and Module2 are library module. Module2 depends on Module1. Both of these modules are platform agnostic and can be ran inside a browser or nodejs.
Module3 is a project module which depends on both Module2 and Module1. It is designed for a browser and uses browserify to combine them all into a bundle.
Module4 is another project module which also depends on Module2 and Module1. This is designed to run under nodejs.
Each module has its own git repo.
Now the problem I am having is to do with relative paths inside the require. For example c.js currently does require("../../Module1/src/a.js"); Similarly h.js does require("../../Module2/src/c.js");
This causes foldering structure to be an absolute pain and each project has to be cloned from git in the correct setup.
The following is what I am trying to achieve.
To do away with relative paths so I simply do require ("ModuleX/src/foo.js"); This needs to work with both browserify and nodejs.
To clone a project module from git and have it get all of its dependent modules (perhaps git submodules?). Not caring about folder structure as this should be solved using the point mentioned above.
Once a project and it's dependent modules have been cloned to be able to edit each of these modules, make changes and push them to their individual git repo.
I imagine what I am trying to do is pretty standard. Creating my own modules and reusing them in different projects. Am I trying to go about solving it in the standard way? I've read that there are different ways to achieve this using NODE_PATH which is supported by both node and browserify but both discourage it. Browserify supports a paths option but doesn't work for node. Also read about putting the modules inside node_modules but not sure how that would help with relative paths.
Any advice would be greatly appreciated
Thanks
What you probably want to do is commit your reusable code to git (here GitHub) and then npm install <git remote url>:. An example would be npm install git+https://isaacs#github.com/npm/npm.git. On the other hand your repo needs a package.json and a index.js holding your code or pointing to it. Alternatively you could define the location of your main file in the package.json via main:"" key.
The dependencies between those projects would be defined in the respective package.jsons. Upon install npm does it's magic to avoid circular dependencies, caching etc.
Once you've done all that you would be able to just var x = require("ModuleX") to get ModuleX/src/foo.js if you so wish to.
Alternatively use npms private modules.