I'm setting up the framework for building a suite of apps in reactjs. They will all communicate with a suite of APIs for the backend. I wanted to build a common JavaScript library "project" where I can put code that could be used by all apps. For instance:
lib
|--api (JS service classes to communicate with API backend)
|--ui
|--components (common shared react components)
..etc..
I would like to be able to start a new app and include parts of the lib - /lib/api/ for example.
I'll be doing a similar setup with the backend code, which is not JavaScript.
What is the best way to structure this so the lib can easily be included in other projects? We're using git for source control but don't know it well. Should these be git submodules? Or should I look at some kind of private npm repository?
You can:
Public them to npm (private or not)
Just add dependencies from git via npm add, as usual
In general, many companies tend to use packages scoped with a #companyname/ namespace. That's what I'd recommend. Whether it's public or private is up to you.
In my opinion git submodules is not what you're looking for. It's more cumbersome to manage than normal npm/yarn dependencies.
Related
I'm pretty new to javascript development so apologize in advance if this seems obvious. I'm trying to build a private npm package that is not accessible to users.
However, I am able to see other npm package code that's supposedly not open-source by going into their respective node_modules subdirectory. So I'm wondering what the difference is between public and private npm packages since one can view the source code via node_modules folder either way.
Thanks for the help!
The privacy setting only affects wether a package can be published to a package registry or not and which people are able to access the package (e.g using restricted packages for custom company packages which are used in several projects). So "private" helps in preventing a package from being accidentally published and restricts the set of users who can access the package.
This is not a way to somehow obfuscate or hide your code from people whom you shared the package with!
While there are ways to achieve what you want to do, it's not as simple as you might think, as JS itself is not a compiled language and ca. (One way would be to write the code you want to hide in another, compiled language, e.g. C, and then call your C library via JS, basically using JS just as a wrapper)
TL;DR: If you grant users access to an NPM package they will be able to see the code of the package, end of the story. You can only decide who will be able to see/access the package by setting the privacy (public/private/restricted) of the package.
We have built a small-ish application using Aurelia, and would like to be able to integrate the app into a larger codebase. For example, it may be desirable to publish the Aurelia app on NPM, so other projects could integrate our code.
How can we build/publish the Aurelia app, so that it can be instantiated in a larger JavaScript application?
Typically, you wouldn't publish an entire Aurelia application to NPM, rather you would push plugins to NPM.
The simplest way to learn how to do this is to follow the example of the various Aurelia repos. We build the code in to multiple formats, but the most important are AMD and CommonJS (which is more important for your company is dependent on what tooling your company is using). Once you've built the code, the next step is to make sure your package.json file is set up correctly. It's best to copy the example of what we're doing in our own repos.
I would start by looking at either the dialog plugin or the templating-resources plugin. Both of these show good examples of how to publish your Aurelia plugin to NPM, whether it is a public or private npm feed.
https://github.com/aurelia/dialog/blob/master/package.json
https://github.com/aurelia/templating-resources/blob/master/package.json
Both of these plugins are set up to support Webpack, JSPM/SystemJS, and the Aurelia CLI out of the box.
I totally agree with #Ashley in not publishing larger applications to the global NPM registry. The big advantage of it is the simplicity of all that small packages which can be used to build large applications.
If you feel you got some reusable code, put in an own package and publish it.
Anyway, to give you an answer which does not require you to publish your complete app: you can include a complete repository (which is probobly what you are lookig for) in a different application via NPM.
npm install git://github.com/somegit/hubrepo.git
Or directly via the package.json:
"dependencies": {
"private-repo": "git+ssh://git#github.com:somegit/hubrepo.git#v1.0.0",
}
You can also do something similiar e.g. using JSPM. This would be simply:
jspm install your-app=github:OrgOrUser/your-app#your-branch
If you are facing long relative paths in your imports now, depending on your tooling, you may be interested in something like e.g. Resolving require paths with webpack which shows how to alias relative paths.
Sources/Links:
How to install a private NPM module without my own registry?
npm install private github repositories by dependency in package.json
I am trying to understand the differences between an Ember addon Vs normal package more from consuming side in my app.
So I would like to understand the following points;
Differences in consuming both ? like what do we need to import, Brocfile changes, etc How are these available to individual modules say inside a route or controller, etc
Is the installation process same for both ? Can both of them live in any repo or registry (like npm or bower registry)
How or where do they reside in the build output i.e. in dist folder ?
How do we decide whether to package something as addon Vs normal package (this is more from a developer perspective)?
You can also highlight any other significant differences.
Disclaimer: this is my understanding, but I have not built an addon myself, so I might have some misconceptions.
Ember addons are basically normal packages with some additional structure that makes them easier to integrate in an ember application.
When using an Ember addon, you import things exactly like with any normal package. The only difference comes from objects that need to be registered with the resolver (services, adapers, helpers, etc): they will be automatically detected, added to your project and registered. This is why, after installing, say ember-notify, you can just Ember.inject.service('notify') in some component/controller and it will work.
The details are for the addon author to choose. Usually, addons will register common objects that benefit from dependency injection (template helpers and services, mostly - though some addons define new injection types and come with some packaged, for instance ember-validations registers its validators). For other functionalities, you import things normally (import thing from 'addon/thing';).
Ember addons are installed using npm (you find them in your project, under node_modules). You can even install them with npm yourself, just remember to add them to package.json so they are included by ember build.
In the build output, they should simply be packaged, altogether, into assets/vendor.js.
I would say the rule of thumb should be: if it is ember-specific, make it an addon. Otherwise, stick to normal package. But really, an ember addon is basically a normal package that has a specific layout.
I am creating a javascript client side library which I will make available via Bower and depends on two other libraries, one that is available via Bower (https://github.com/abritinthebay/datejs) and another that is available only via npm (https://github.com/fent/randexp.js). I am concerned about how the users of my library would go about using it. My doubts and fears are:
how can I declare the second library as a dependency of my library when it's only available via npm?
after the user installs my library, will he/she have to be aware of the dependencies and manually include the corresponding javascript files in their index.html? I am aware of grunt-bower-install solving this issue, but I'm concerned about people who don't even use grunt at all.
would it be so bad if I just gave up on all of this and included the code of said libraries in my own code?
(bonus round): I want my library to be available as an AngularJS service, as a node.js module, and as a 'normal' javascript function. Is there a way for me to achieve this using only one repository or do I have to create 3 separate projects?
1) You need to wrap the second library in a bower package if you want it to be available to the bower package management system. npm is something entirely different and you won't be sharing between the two directly.
2) Yes, the user needs to ensure the dependencies are loaded in the right order on each page. Bower just ensures your dependencies are installed and at the correct version.
3) Generally, I'd avoid this. They're separate projects with orthogonal concerns. This is why we've created package managers like bower to begin with.
Bonus:
4) Yes, you can achieve this with one repository. Each package management service requires their own configuration files - but there's nothing wrong with having a bower.json and a package.json both sitting at the root of your repository. You just use npm and bower separately and respectively to publish to each system.
PS. This should have been more than 1 question.
I have two node.js (more specifically, express.js) projects. Lets consider "project A" which is the main project, and "project B" which is an "ad-hoc" (for a certain purpose) project. Project B needs project A models.
How to re-use project A's models wisely without repeating code? (And how is it working practically, in terms of how the two projects are arranged?)
Thanks.
A decent approach to deal with this would be to separate it as a module you can install using npm. (You can install private packages with it)
This would allow you to easily manage any dependencies your library has. You can define them into the package.json file, and whenever a project needs the library, you simply install it and npm deals with the dependencies.