I have an external node package installed in my project. It does 90% of what I want but I'd like to make some changes to it. I don't want to submit a PR to developer since these changes are unique to my situation and would only be used by me. What would the best way to go about this? Inside my node_modules folder, the JS file of the library is minified so it's hard to make out anything or edit anything in a coherent manner.
You shouldn't be really messing about with the node_modules folder, as the code is usually minified (as you have stated).
However, the most reasonable approach to do is to follow the steps below.
Fork the repository on GitHub, and add whatever changes you need to add in the forked repository.
If you want, you can make a new npm module (if you have an account), and install that in your project.
Otherwise, you can just add it as a folder in your project, or something like that.
Make sure that this isn't overkill for your project!
In conclusion, you shouldn't make changes to the node_modules folder, but you can fork the repository as an alternative.
Related
Javascript dinosaur here. Back in the good old days, customizing a JS library was pretty easy. I'd download the non-minified version, put that sucker on the /js folder, do the changes necessary to the code and embed it on the html. Like this:
<script src="Sortable.js"></script>
Enter the marvelous world of modern javascript, a great advance where no project folders have less than 14mb. In this world, I don't download the file and put it on the /js folder, I install the package with 12 warnings and import it, and then a little program compiles it for me every time I need to test it. Takes 10x longer, but hey, my code is now compatible with the 0.0003% of users who use Internet Explorer 4. Wonderful. Anyway, this is the modern code:
import Sortable from 'sortablejs/modular/sortable.core.esm.js';
Sarcasm aside, I have a serious question: When customizing a library in a modern setup, of course, I won't change the final compiled version as it would be overwritten in a new build. I also wouldn't change the files sitting in node_modules folder, because these will be overwritten with every update. So what's the best way to do this?
Something tells me I have to fork the library, put the fork on npm and import the fork. I don't want to believe it. Is this really what I have to do to customize literally 2 lines of code?
If I had such a task, I would rather download the source code, do the changes, build it, and "install" it as a dependency using Local Path:
{
"name": "project",
"dependencies": {
"sortablejs" : "file:../path/to/sortablejs/bin"
}
}
But it's difficult to update the package with those changes. That's why you may consider using something like patch-package or using Yarn's yarn patch <package>, which lets you keep your changes separately from your package (in theory, I've never used it before).
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
I'm using a package that loads Font Awesome from a CDN. However, the CDN used is pretty terrible, often stalling or timing out, so I'd like to switch it out.
The source code is incredibly simple, and looking through it I found this:
style.href = '//maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css';
Switching to a different CDN would only require changing this one line (I presume), but the problem is I don't know how! Or rather, I don't know where it is available in my project.
How do I actually do this?
Create a packages/ directory at the top level directory of your app (myapp/packages) and simply git clone the package you want to modify into it.
Add the package via meteor add and you'll be able to edit the files of the package you just cloned.
I have 2 projects. They use same js/img files. When I change js content in first project I should also change it in second project. I wanna make it as dependency. So I deploy changes to my local repository, then goto project1/project2, call update and changes are loaded.
I have tried to use bower but it doesn't satisfy me because of some strange behaviour (it copies whole folder content and ignores main section in component.json)
How can I implement normal dependency managment in my project? note: I need to manage my local dependencies
The main property in component.json is currently only used for other tools using Bower. There is currently a discussion going if Bower should have a .bowerignore file for ignoring files it doesn't need.
You might be better of just using a git submodule or symlinking the files.
Alternatively you could check out if any of the other JS package managers fills your need: npm, Ender, volo, component, jam
Another option (if you just want to fetch single files) might be: pulldown.
Configuration is extremely simple and you can easily add your own files/urls to the list.
I am in the process of converting an existing Rails 3.1 app I made for a client into a Backbone.js app with the Rails app only as a backend server extension. This is only a personal project of mine, to learn more about Backbone.js.
While setting up Backbone.js (using Backbone-on-Rails), I noticed I have some dependencies (like backbone-forms) that come from external sources and are frequently updated.
I've grown accustomed to using Bundler to manage my Ruby gems, but I haven't found anything similar for JavaScript files. I'm wondering if there is any way to do the same for Javascript (and possibly css) files.
Basically I can see three possibilities to solve this issue:
Simply write down all the sources for each JS file and check these sources from time to time to see what has changed.
Use some kind of existing "Bundler for Javascript" type of tool, I've been looking for something like this but have yet to find anything (good).
Since most of these JS files will be coming from Git anyway, use Git to get the files directly and use checkout to get the latest version from time to time.
I prefer the last option, but was hoping on some more input from other people who have gone this route or preferred some other way to tackle this issue (or is this even an issue?).
I figure the Git way seems easy, but I am not quite sure yet how I could make this work nicely with Rails 3.1 and Sprockets. I guess I'd try to checkout a single file using Git and have it be cloned in a directory that is accessible to Sprockets, but I haven't tried this yet.
Any thoughts?
You don't mention it in your alternatives, but ideally you should use something like Maven to manage your dependencies. Unfortunately, there are no public repositories for javascript files. This discussion lists some other options which might be of help to you: JQuery Availability on Maven Repositories
For now I've settled on using the Git solution combined with some guard-shell magic.
The steps I follow:
Create a dependencies directory somewhere on your local drive
Clone the repositories with javascript (or css) files you want to use in the app
Set up a custom guard-shell command to do the following:
group 'dependencies' do
guard 'shell' do
dependencies = '~/path/to/dependencies/'
watch(%r{backbone-forms/src/(backbone\-forms\.js)}) {|m| `cp #{dependencies + m[0]} vendor/assets/javascripts/#{m[1]}` }
end
end
Place the Guardfile at the root of the app directory
It takes some time to set things up, but after that, when you have the Guard running, and you pull changes into your dependencies, the required files are automatically copied to your application directory, which are then part of your repository.
It seems to work great, you need to do some work for each new file you want to include in the asset pipeline, but all that is required is cloning the repository in your dependencies directory and adding a single line to your Guardfile, for example for the backbone-form css:
watch(%r{backbone-forms/src/(backbone\-forms\.css)}) {|m| `cp #{dependencies + m[0]} vendor/assets/stylesheets/#{m[1]}` }
Also, the reason I added this Guard to a group is because I keep my dependencies outside the main application directory, which means guard normally doesn't check my dependencies directory. To make this work, I start up my main Guard processes using bundle exec guard -g main and use bundle exec guard -w ~/path/to/dependencies -g dependencies in a new terminal window/tab to specify the -w(atchdir).