I am wondering what is the best way to keep archives/older versions of a specific module I am developing for nodeJS.
Say I have SampleModule v1.0.5 then later on I will be releasing SampleModule v2.0.0. I want to retain both versions in my node_modules folder since another app will only need SampleModule v1.0.5.
What is the best way to do this? Should I just have 2 diff folders: samplemodule105 and samplemodule200 then call something like require('samplemodule200') or require('samplemodule105')?
Also, so basically require() checks the folder name rather than the name and version inside a module's package.json right? This folder and name are only used to fetch the library via npm install?
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 am a relative newbie to node.js and typescript and am looking for tutorials and examples for building custom libraries for typescript. I am currently working on a project(switched to WebStorm GUI) that requires I build several microservices and several of the microservices will need to share certain code, i.e., base repository functionality, etc. My though would be to move the code they have in common to a series of separate libraries(projects) and make them into typings and have the projects that need them to install them. Following the example I found here, and using grunt: What is the story for creating and consuming TypeScript libraries?, I was able to generate the .js file and the .d.ts files in a dist folder on the project. There are a few areas that I am confused about:
1) The example makes reference to a "main": "./dist/my.service.js" section in the jsconfig file, how necessary is this file and what should go into it?
2) If all of the files are transpiled and added to the dist folder, will the dependent code still be able to access it or do I have to transpile all of the files to root?
3) After I have have all of the file successfully transpiled and moved to the proper location, how do I install them to the dependent project if they are local and not up on the npm or Definitely Typed, etc.?
Well if you would like to see an example project that I am currently working on that at the moment can be installed with npm is binary-type-tree. There are some things I need to fix but overall the project is working great. You can see my setup for Jest in my package.json. Along with how to set up the types and the main.
Depending on what your library will be focused on you will want to choose the appropriate module system. Right now commonJS is the most common for npm packages. Although you can only compile to one file with system or amd.
As for compiling you do not need gulp/grunt you can use Webstorms IDE to compile your files. Simply open up the Webstorm settings "Languages and Frameworks" and select "Typescript" there you will see enable Typescript compiler.
The example given is very old. Typescript had a major update to how typings work back in October of 2016, they moved to Typescript 2 I think, or maybe it was November. Anyway when you google search Typescript I would set the filter to not before that time.
1.
The main in the package.json of the Typescript project should point to the entry point of your library, or your executable. Since mine is a library it points to the compiled folder's index file. The file does not exist in my repo but it is there upon compilation.
2.
This I believe is answered depending on your build. In my build as an example I use module system es6 as you can see in my tsconfig.json file. This uses the ES6 module system.
if you would like to use commonjs the structure of my project will still work properly except you will need something like Systemjs or Babel on the front end.
3.
This one is a bit unknown to me but what I have done for only testing is copy my directory into the node modules of another project I am working on. Now to require the project you do not need a #types since I have "declaration": true in my tsconfig.json file. The package.json of my project has a "types": section which points to the compiled .d.ts file. The project that is requiring this new TS package, if also written in TS, will have to have the typeRoots and types section in the tsconfig.json file. Once this is all set up you should be able to require it just fine.
Make sure that the src of all your TS files is declared in the includes section of the tsconfig if your files are not compiled to root. Otherwise your project will have to require in files in an odd format like import * as BTT from "lib/basic-node/avl-tree";. Which is not what I wanted, once I added this it became import * as BTT from 'binary-type-tree';.
The "main" field in your package.json tells Node's module system what file to require when calling require(), so you will definitely need it. You point that field to a transpiled file, which will also contained transpiled references to your other transpiled TypeScript files, so you shouldn't have to add anything to root.
If you're trying to use the package from another project, you simply reference it as a dependency using NPM the same way you would with any other JS project.
{
"name": "dependent-project",
"dependencies": {
"bar": "file:../typescript-project"
}
}
Again, Node will know how to load the TypeScript project because you've specified the transpiled entry point in the main field.
There are several things you must consider:
In package.json, you must set some things up (example):
main property to point to your UMD compatible bundle
module property for ES5 module. Then modern workflows can benefit from it, for example to apply Tree Shaking
typings pointing to your .d.ts file (which should be generated)
That counts on a build process, which can be made with a module bundler, such as RollupJS or Webpack. They can generate source maps and so on.
As per question 3: you can install packages from local or even from Git repos. In your package.json, for example:
"your-library": "git+https://github.com/alexjoverm/typescript-library-starter.git"
I'd suggest you to take a look at TypeScript Library Starter. You can find there everything you need. It has configured out of the box:
Automatic releases
Package.json configuration
Universal module bundles
Source Maps
Typings (.d.ts) auto generated
Docs using TypeDoc
Tests and coverage
Node/NPM newbie with a front-end dev question. I understand one of the strengths of an NPM-type module is that its dependencies get installed within itself, in node_modules. Modules always have the code that they need, and outside libs don't conflict.
That said, seems like this would result in the client downloading the same lib+ver (say, jquery v.X) multiple times. What's the technique for specifying that a module needs a dependency but that it shouldn't package that code if the dependency is already available on the site/page? Does said technique involve parent modules that make the shared lib+ver available?
Or, should various front-end modules just re-download the same lib+ver that other modules on the page might have already downloaded?
The client will only grab files from that folder that are needed, so if it's linked in HTML once the client will only grab it once. NPM handles dependency duplicates automatically.
Having said that, normally you will want to only serve a static folder to the client without revealing your entire server structure. This can be achieved using:
app.use(express.static('server/public')
where 'server/public' is the directory relative to the server.js file that you want to serve. In this case, 'public' contains all my linked view files, stylesheets, JS files, etc. that are linked from the HTML pages. You don't need to move that module's dependencies there as well.
The downside to this is that you'd have to manually move dependencies into the public folder (I make a 'vendor' directory usually) and link from there. It's more work but it's much more efficient and safer in the long run.
NOTE: when using a static folder to serve files, your HTML links will be served from a relative path to that folder.
I am building a server app as a "core" framework and (potentially) multiple specialisations, starting with "spec_a".
I would like "core" to be an npm package, and "spec_a" to be an npm package which requires "core".
While I could require spec_a's modules and pass them to core in function calls, I would prefer core to read a config file and try to require modules (which are specified in the config file) from it's parent package. (The core shouldn't need to know the name of its parent package, as it will be different from each specialisation.)
What I am looking for is a require_from_parent(module_name_from_config) call.
Is there a way of making such a thing?
I was thinking of using require('../'+module_name_from_config), but this is fragile and will probably break on the latest npm.
I think I found the answer here on a nodebb blog.
var Topics = module.parent.require('./topics'),
User = module.parent.require('./user'),
Notifications = module.parent.require('./notifications');
There is no explicit "requireFromParent" call. Whenever you call require, it will first look in its own node_modules folder and if the module is not found, it will traverse up the directory tree and check if its parents have the module, which should work for your purposes.
I have a folder that contains all my cloned GitHub repositories. Now I would like to get a list of all the repositories that reference a given dependency.
I think of something such as:
$ whouses async
And then I'd like to get a list of all repositories, where async is either referenced as a dependency or a devDependency. Basically, all whouses would need to do is to enter each sub-folder of the current folder and check the package.json file.
Is there a tool available that does this, or am I better off writing one for myself?
Well, there's a way to browse the npm registry for all published modules that depend on a library: https://npmjs.org/browse/depended/async. That may help you a bit. For a local set of modules I don't know off the top of my head if anything exists already or not.