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.
Related
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.
I'm just starting with Bazel, I want to create a rule that copies my nodejs application (folder) inside the sandbox, copies other local packages (referenced in package.json using the file:// annotation) and perform a npm install action.
The output directory should then be a distributable nodejs application with the node_modules/ already set and working (or this is what I want to get).
I've tried by starting over this rule but I can't seem to perform any modification over it and I don't know where to go from there since the logic is pretty hard to follow.
I also tried to start with an easier action but I cannot get it right, especially regarding the local libraries, because it won't allow me declare as glob any file containing "..".
Can you please give some advice to get started?
If possible I'd also like to know how could I dynamically generate a JSON file, so I'd be able to declare my node dependencies in bazel itself (being able to track them down and centralize their version).
this won't be an easy exercise :) It's perfectly doable, and at the end you'll be perfectly comfortable understanding what that rule does :)
I suggest you to read the documentation on writing extensions and custom Skylark rules to start. Be sure to start small and iterate.
It's quite cumbersome to work with directories, you might want to create a tar first. You can also perform npm install if you really want to, but it will have caching and remote execution implications.
And of course, you can generate json in Skylark.
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.
To be completely specific:
I am writing a Node.js app that is intended to be a websocket bot for Slack.
A Node project exists that abstracts the majority of the Slack API. (It is NOT an npm module.)
I'm not overly familiar with grunt, etc. but I can get the dependencies to install and utilize all this code by placing my own mybot.js in the root folder of this git clone and running node mybot.js with mybot.js being based on the files in the example folder.
Committing to my own repository, I don't want to commit any of the aforementioned project code -- it's not mine! I do, however, want it as a dependency. Unfortunately, this code by Slack is not an npm module that makes it easy to do. The project has a /bin folder and a /src folder full of coffee script, etc. that grunt builds to .js files.
The Slack project code has its own dependencies. In my way of thinking, those are sub-dependencies for me, or cascading dependencies. My project only depends on whatever the Slack project depends on.
I would like to be able to update my project with updates (manually, or via build) from the git repo of the Slack project as needed.
It seems there must be a way for me to include this project as a dependency, and once built, properly reference it's bin and src folder objects (bin/slack, src/message, client, channel, user, etc.) without committing it to my own repository. Especially great if it could be in a subfolder separate from my own model definitions. In a way, this seems no different to me than including jQuery in my website layout via a CDN. I'm only asking for the jQuery project and depending on my link flavor, I can get a specific version or the latest version, etc.
So, it turns out the comment by Ben pointing me to the npmjs.com slack-client npm module was the help I really needed. I just didn't really know how to ask the right question, I think.
And while I hate to look a gift horse in the mouth, a little more than a link, Ben, would've saved me another three hours, probably. Perhaps: "It is an npm module, not just a project from github." But thank you, even if it took me a while to decipher what you were saying.