I'd like to publish an NPM package, but closed source. I'm well aware of private packages, but that's not what I am looking for. I'd like to publish an package that everyone can use, but not everyone can inspect the code from.
I want to first build my code as a closed-source library, and then publish it to npm. How can I achieve such a thing?
I looked into uglyfying my code first, but will that obfuscate it enough?
It would be really nice to just package it like pkg does, but that does not allow packaging as an npm module.
As far as I know there's no real way to do this in the way you want. Code can be de-uglified easily.
You can write the code in a separate language like C, then compile it and write a javascript wrapper around it using native modules.
You can also put a really restrictive license on it which is displayed on the npm website when people view your module. But the code can still be viewed and it would be up to you to go after any people that break your license.
But since javascript isn't a compiled language there's no easy way to do this at the moment.
Related
I am currently working on making a web extension application(chrome app) and I want to use npm in my application. When I want to use npm on my computer, I had to simply download and install it on my computer. But if I want to put it into my application, I am not sure how to include this.
Like bootstrap, do I need to include a min.js file such as bootstrap.min.js?
(what I want to do with npm is to make a crawling to happen using cheeriojs!)
Is there anyone who knows how to include npm in this case?
Thanks in advance!! Any advice would be much appreciated! :)
npm is a package management tool. It has no place being in a Chrome extension.
If you want to use packages from NPM in a browser extension, then you'll typically want to use a tool like Webpack to transpile them from module format into a single ES5 file.
Note, however, that cheeriojs is:
Fast, flexible & lean implementation of core jQuery designed specifically for the server.
… and since you want to run this in a browser, you should probably just use jQuery!
I have a library and want to encourage/force users to use the locally installed version only. I could do this the hard way or the easy way.
The easy way would be if NPM had a mechanism to prevent using the --global switch with the npm install command, for any library.
The hard way would be to add code in my NPM packaged that returned early if the code determined it was globally installed not locally installed.
Does anyone know if you can prevent global installations of an NPM package? What might be the most user friendly way to approach this?
The best way to prevent users from installing your module globally would be to describe your preference in the documentation.
There is nothing you can do to force your users to never install it globally if they can install it locally. They will always be able to move the files manually if they want.
In the npm community the assumption is that the user has control over the modules he/she uses, not the other way around. Forcing people to use your module in certain ways will only make them unhappy.
So the only good answer to your question is to document the way your code should be used. You can ask them to use your module a certain way - but they are the ones who can choose to listen to you or not. You can state that using your module installed globally is unsupported, unwise, discouraged, dangerous, but you will not be able to force users to use the module as you want, and that's a good thing.
Now, for some bad answers, you can always test if the parent of your module's root directory is named node_modules or not and fail if it isn't but I'm sure it can cause some trouble if someone happens to install your module locally as you want but under a different directory. You can see if your module is run from one of the default paths that node uses to search for modules but those paths are not always the same, and you'd have to take the NODE_PATH environment variable into account as well.
You can do few tricks like that but they can only annoy users who know what they are doing because they will have to change the source code of your module to do what they want, and they will always be able to do that, no matter how hard you try to make their life harder.
In summary, my recommendation would be to document your module well and respect your users and their needs, and trust them to know what they're doing.
Update
For a working example of a Bash function that prevents global npm installation of a certain module, see this answer - section Working example of preventing global install.
In node js, we import require('library') to use external library. let's say there's a external-file.js inside 'library' that we want to customise for our project. What is the technique that can be use?
In Java, this can be done irreverently through just copying the external file and make sure it adhere to same package path. How can this be done in node.js ?
Ideally if this external library is getting pulled from npm or github, you should create a fork, use that in your project's package.json and modify the file in your own fork. Then when you commit the changes to the file, it'll go into your own version of the third party library. (And if the change is good enough you can even ask the author to incorporate it in their code and get credit for contributing to open source :D)
Additional benefit of doing it like this is that you won't have to commit the dependencies in along with your source code.
What exactly should I put in .npmignore?
Tests? Stuff like .travis.yml, .jshintrc? Anything that isn't needed when running the module (except the readme)?
I can't find any guidance on this.
As you probably found, NPM doesn't really state specifically what should go in there, rather they have a list of ignored-by-default files. Many people don't even use it as everything in your .gitignore is ignored in npm by default if .npmignore doesn't exist. Additionally, many files are already ignored by default regardless of settings and some files are always excluded from being ignored, as outlined in the link above.
There is not much official on what always should be there because it is basically a subset of .gitignore, but from what I gather from using node for 5-ish years, here's what I've come up with.
Note: By production I mean any time where your module is used by someone and not to develop on the module itself.
Pre-release cross-compiled sources
Pros: If you are using a language that cross-compiles into JavaScript, you can precompile before release and not include .coffee files in your package but keep tracking them in your git repository.
Build file leftovers
Pros: People using things like node-gyp might have object files that get generated during a build that never should go into the package.
Cons: This should always go into the .gitignore anyway. You must place these things inside here if you are using a .npmignore file already as it overrides .gitignore from npm's point of view.
Tests
Pros: Less baggage in your production code.
Cons: You cannot run tests on live environments in the slim chance there is a system-specific failure, such as an out of date version of node running that causes a test to fail.
Continuous integration settings/Meta files
Pros: Again, less baggage. Things such as .travis.yml are not required for using, testing, or viewing the code.
Non-readme docs and code examples
Pros: Less baggage. Some people exist in the school-of-thought where if you cannot express at least minimum viable functionality in your Readme, your module is too big.
Cons: People cannot see exhaustive documentation and code examples on their own file system. They would have to visit the repository (which also requires an internet connection).
Github-pages objects
Pros: You certainly don't need to litter your releases with CNAME files or placeholder index.htmls if you use your module serves double-duty as a gh-pages repository as well.
bower.json and friends
Pros: If you decide to build in your dependencies prior to release, you don't need the end-user to install bower then install more things with that. I would, personally, keep that stuff in the package. When I do an npm install, I should only be relying on npm and no other external sources.
Basically, you should ever use it if there is something you wish to keep out of your npm package but checked-in to your module's repo. It's not a long list of items, but npm would rather build in the functionality than having people stuck with irrelevant objects in their package.
I agree with lante's short and syntetic answer and SamT's big answer:
You should not include your tests in your package.
Your package should only contains production runtime files.
That will make your package more straightforward and faster to be dowloaded.
My contribution to those answers:
.npmignore is the blacklist way to achieve package file selection. But in a more practical way, you can whitelist files you need to include in your package using the files field in your package.json:
{
"files": [
"lib/",
"index.js"
]
}
I think that's simpler, future proof and have better semantics ;)
Just to clarify, anytime someone do npm install your-library, npm will download all source files that the package includes. Those files that were included in the .npmignore file in the source code of the package your-library will be excluded when publishing the lib, so users of your-library won't download them.
Know that people installing your library will need just your library running, anything else will be not necessary.
For example, when someone installs a library, its probably that he/she doesn't care about your .travis.yml or your .jshintrc files, or even some images, Grunt files, documentation, etc.
.npmignore could let your npm package to have less files, and faster to be downloaded
Don't include your tests. Oftentimes tests are like 5x the size of the actual codebase. As long as your tests are on Github, etc, that's good enough.
But what you absolutely should do is test your NPM package in its published format. Create some smoke tests that reside in the actual codebase, but are not part of the test suite.
You can read about testing your package after tarballing it, here:
https://github.com/ORESoftware/r2g
How to test an `npm publish` result, without actually publishing to NPM?
I'm putting together a module I'd like to release, but am a bit stuck on how best to go about packaging it up. In addition to server side javascript, the module will need things like an admin screen, and client side javascript files. That is, it needs to serve out a fixed set of static html/css/js files. (I may have the node-static module as a dependency)
I'm curious what is the best way to handle this. I'd like to make this simple to install and integrate into apps, without forcing the user to dig through a long README. Basically they should be able to NPM the module, then add a line or two of code in the relevant place, and have it "just work". I don't want them to have to download other stuff, tell the module where to find the static files, etc.
Also, I'd like to make sure it can be included in both simple apps (i.e. one step from the standard "hello world") as well as complex apps using frameworks etc like Express, without undue hassle.
Is this possible, or is this beyond the scope of what the module system is designed to handle?
Once your package in installed with npm install mypackage -g you can use __dirname inside your executable to find the directory it's running in.
Likely /usr/local/lib/node_modules/mypackage/bin/mypackage
With your assets in /usr/local/lib/node_modules/mypackage/assets
so __dirname + '../assets' + myasset should correctly find your asset