I'm working on a fairly large project where our code is split into separate modules. (Mostly because we're re-using this part over different services)
This becomes a problem when we're working across these different modules, it's a bit annoying to constantly push changes to github and run an npm install again in order to get these into a different project.
Is there a way to overwrite the location of a node module when in development? Basically while developing I just want to import the module from my local filesystem, while on production it want it to be imported from the git source.
You'll want to use npm link https://docs.npmjs.com/cli/link
This will allow you to create a direct link in your node_modules to a local version of your modules.
Related
so far i've learned a bit about NodeJS. But now i want to write a huge enterprise app with it and i'm wondering how to setup the structure correctly? Coming from other languages like PHP and Java, i imagine, i would split my project in different NPM modules. For example #mybigproject/customer, #mybigproject/cart and #mybigproject/checkout and so on.
But those submodules would be installed in the node_modules folder of the application skeleton. How would i tell for example Express, that the template files are in the different module directories? Or for example i use TypeORM for data access. So each module would have it's own set of models. How do those models know the database configuration data, as it's only in the main application skeleton, or the other way around, how does the application skeleton should know where to find the models?
Don't use npm modules for different parts of your project.
This components is integral part of your project and usually depend on your global config / schema / routing / etc
Just put it in different files and require it where you need it.
You can get an idea for folders structure from projects like Sail.JS
Use npm modules if you writing some utility that going to serve you for different apps and you want an easy way to upgrade the utility code once for all your apps (or in case you want to share that utility as open source for all of us)
NPM can install your local folder as a dependency. (ref)
npm install <folder>:
Install the package in the directory as a symlink in the current
project. Its dependencies will be installed before it's linked. If
sits inside the root of your project, its dependencies may be
hoisted to the toplevel node_modules as they would for other types of
dependencies.
Your module keeps its original location after installed and a symlink is created as the same name of your module folder in the top level node_modules folder.
In these custom sub-modules, you can use __dirname and relative paths to locate you configuration files to feed to database or other data consumers.
But remember that, sub-modules often serve as utility functions for the main module. They should be independent from the project context.
I'm working on a web application that currently uses vuejs for part of its interface. The back-end is NOT in Node, so there is currently no package.json file or any tool from the typical npm stack in this repository.
We already have a bunch of non-npm dependencies that need to be installed in order to use the repository, so my coworkers aren't too open about the idea of adding another layer of complexity. I can't blame them for that, it's the reason why I use npm scripts and not even gulp in my other projects. I'm tired of spending hours learning and configuring build tools that never end up doing what I want anyway.
But since the vue-cli tool no longer includes the build command, I'm a bit stuck. Is there really no more CLI app to build vue files at all? And if so, what would be the smart way to use vue without webpack? Template strings are not maintainable at all, and <script type="text/x-template"> don't work when you want to use multiple components from multiple files in the same page.
I realize your question says 'without webpack' but you may be interested in backpack - a CLI app i came across for building Vue.js without requiring you to write any configuration code. It is basically webpack preconfigured as a minimalistic build system for Node.js. It provides two commands, dev for live reload enabled development and build for building you project.
In a node.js project, I'm using Go for a critical part of it that node isn't adequate enough to handle. I want to split the Go code into a sockets package and a main package, with sockets containing required structs/interfaces for the main package to run. The problem I'm having is that from what I can gather from Go's documentation, I can only use external packages like sockets remotely from github/gopkg. I don't want to split the repository for the project into one containing the Go code and one containing node's. How can I make the sockets package available for main to import locally while making it possible to rebuild the binaries for the two packages if any updates to their source code are made?
Edit: importing the packages is no longer an issue, but rebuilding packages on update still remains
It happens the same to my team too and we end up using vendor it's pretty easy to manage all the external packages. So, whoever checkout your repo will have all the packages inside vendor.
Understanding and using the vendor folder
And Please refer this site lots of other option out there too:
Golang Package Management Tools
Project A contains a few functions and data models I use in diff't repos, all tied to the same product. I'd like to turn them into an npm module, but without extracting the code from project A.
When I see other modules on npm, they generally tie to a github repo that contains all the source code, as well as a full stack to run/modify the module.
Does this mean I have to extract the code from project A into its own repository, build/configure a stack to allow it to run in isolation from project A, and then import it back into project A & other projects?
Or is it possible to just export the functions w/o a full stack, and without moving the code from my main project?
an attempt to pre-empt 'duplicate' comments:
this Q talks about working with an existing module, which doesn't answer my concern, as it has to do w/ worrying about pull requests being merged on time
npm link, discussed here, looks like it'd do the trick if I'd already extracted the code from the project, but I'd like to avoid that.
If you really want to share a snippet through npm but still use the code at the same place in your project, you could extract the code into its own repo, but still use it inside your project as a git sub-module.
Create a submodule repository from a folder and keep its git commit history
Do you know if it's standard for npm modules in their own repos to include the full stack for running them?
Ideally, it's to test them and ease the development, but it's totally optional. You could only put a JavaScript file and the package.json and it would work.
I have a repo which consists of several "micro-services" which I upload to AWS's Lambda. In addition I have a few shared libraries that I'd like to package up when sending to AWS.
Therefore my directory structure looks like:
/micro-service-1
/dist
package.json
index.js
/micro-service-2
/dist
package.json
index.js
/shared-component-1
/dist
package.json
component-name-1.js
/shared-component-2
/dist
package.json
component-name-2.js
The basic deployment leverages the handy node-lambda npm module but when I reference a local shared component with a statement like:
var sharedService = require('../../shared-component-1/dist/index');
This works just fine with the node-lambda run command but node-lambda deploy drops this local dependency. Probably makes sense because I'm going below the "root" directory in my dependency so I thought maybe I'd leverage gulp to make this work but I'm pretty darn new to it so I may be doing something dumb. My strategy was to:
Have gulp deploy depend on a local-deps task
the local-deps task would:
npm build --production to a directory
then pipe this directory over to the micro-service under the /local directory
clean up the install in the shared
I would then refer to all shared components like so:
var sharedService = require('local/component-name-1');
Hopefully this makes what I'm trying to achieve. Does this strategy make sense? Is there a simpler way I should be considering? Does anyone have any examples of anything like this in "gulp speak"?
I have an answer to this! :D
TL;DR - Use npm link to link create a symbolic link between your common component and the dependent component.
So, I have a a project with only two modules:
- main-module
- referenced-module
Each of these is a node module. If I cd into referenced-module and run npm link, then cd into main-module and npm link referenced-module, npm will 'install' my referenced-module into my main-module and store it in my node_modules folder. NOTE: When running the second npm link, the name of the project is the one you find in your package.json, not the name of the directory (see npm link documentation, previously linked).
Now, in my main-module all I need to do is var test = require('referenced-module') and I can use that to my hearts content. Be sure to module.exports your code from your referenced-module!
Now, when you zip up main-module to deploy it to AWS Lambda, the links are resolved and the real modules are put in their place! I've tested this and it works, though not with node-lambda yet, though I don't see why this should be a problem (unless it does something different with the package restores).
What's nice about this approach as well is that any changes I make to my referenced-module are automatically picked up by my main-module during development, so I don't have to run any gulp tasks or anything to sync them.
I find this is quite a nice, clean solution and I was able to get it working within a few minutes. If anything I've described above doesn't make any sense (as I've only just discovered this solution myself!), please leave a comment and I'll try and clarify for you.
UPDATE FEB 2016
Depending on your requirements and how large your application is, there may be an interesting alternative that solves this problem even more elegantly than using symlinking. Take a look at Serverless. It's quite a neat way of structuring serverless applications and includes useful features like being able to assign API Gateway endpoints that trigger the Lambda function you are writing. It even allows you to script CloudFormation configurations, so if you have other resources to deploy then you could do so here. Need a 'beta' or 'prod' stage? This can do it for you too. I've been using it for just over a week and while there is a bit of setup to do and things aren't always as clear as you'd like, it is quite flexible and the support community is good!
While using serverless we faced a similar issue, when having the need to share code between AWS Lambdas. Initially we used to duplication the code, across each microservice, but later as always it became difficult to manage.
Since the development done in Windows Environment, using symbolic links was not an option for us.
Then we came up with a solution to use a shared folder to keep the local dependencies and use a custom written gulp task to copy these dependencies across each of the microservice endpoints so that the dependency can be required similar to npm package.
One of the decisions we made is not to keep two places to define the dependencies for microservices, so we used the same package.json to define the local shared dependencies, where gulp task passes this file and copy the shared dependencies accordingly also installing the npm dependencies with a single command.
Later we made the code open source as npm modules serverless-dependency-install and gulp-dependency-install.