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.
Related
I have a typescript monorepo with front end, cloud functions, and back end (docker) packages in it. I'd like to add a "common" package that can be used by all of those.
Some production environments like Google Cloud Functions and Docker (at least in one common usage) package up the current app's directory and send it to a remote server, where it does "yarn install" to install all the dependencies. This means the obvious ways of referencing the common package (import * as common from "../../common" and the like) don't work because the build server won't find common there.
Also, sadly, docker and GCF don't follow symlinks, so the yarn link: protocol isn't helpful.
And since I'm working on the common code just as much as the apps, I really don't want to publish it to a private NPM registry every time I make a change. I'd like that change process to be as seamless as possible.
The most seamless way is to just symlink common into each app's node_modules, but (a) yarn deletes those, and (b) the builders don't follow symlinks. So I assume I'll need some kind of build/push process when changing the common code.
It seems like a kind of common thing to want to abstract out common code into its own module that can be used anywhere in the monorepo, but I can't find a solution that works. (For extra points I'd like "jump to definition" in my IDE to go to the actual definition, not a local copy.) Any ideas? Can Yarn 2 help with this use case?
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.
Assuming I have the following project structure:
webapps
ProjectA
SomeClass.ts
Package.json
ProjectB
SomeClass.ts
Package.json
Common
LoggingClass.ts
Package.json
The Common "LoggingClass" need to import a module from NPM. Let's assume that module is UUID (https://www.npmjs.com/package/uuid)
The problem, or the challenge is the following: We want to use and import the "LoggingClass" in both ProjectA and ProjectB.
Thing is, they can import the code from the common folder without a problem, but then the module "UUID" is not existent in those project because we did not specify so in their own respective Package.json.
I do not want to create actual node modules since my code needs to be checked into a git repository. (Some people recommend to develop directly into node_modules directory).
I would like to know what other fellow typescript developers do in the community to share their code when using npm. (If it was only typescript files it wouldn't be a problem, but because of the dependencies we have on npm.. it gets complicated).
Any thoughts would be greatly appreciated !
I do not want to create actual node modules since my code needs to be checked into a git repository.
A real npm module is actually a way to go IMHO. You don't have to store it specifically in npmjs.org (you can have an own npm repository).
Some people recommend to develop directly into node_modules directory.
This is actually the most inconvenient way I can imagine of. Probably, I'm missing something important, but I'd love to know their way of thinking.
There are things you will not be able to [easily] achieve with git-only based solution. For example, how would you checkout a specific version of the shared code, with keeping the rest of the code intact? It is relatively easy when you have only one directory where all the shared code lives. But if you have many (basically, directories-as-packages) then it gets cumbersome. And even figuring out their "versions" is tricky too -- you'd have to invent and follow a git tagging rule or some other way to annotate commits.
Anyways, what I am trying to say is that my answer is not exactly what you asked for; my answer is rather a suggestion to reassess you position regarding (not) packing code into an npm module -- which is de facto a standard in the JavaScript/TypeScript community for a reason.
I would like to know what other fellow typescript developers do in the community to share their code when using npm
Since your requirement I do not want to create actual node modules since my code needs to be checked into a git repository.
I would simply reorganize as
webapps
package.json
projectA
SomeClass.ts
projectB
SomeClass.ts
Package.json
common
LoggingClass.ts
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 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.