Get package.json of package using HTTP from public repositories - javascript

Maybe this question has already been asked but after a bit of googling I haven't found anything reasonable.
The main goal I'm trying to achieve is to obtain a dependency tree of a specific npmjs library of specific version e.g. obtain dependency tree of library angular of version 1.5.3
Now, I would like to use HTTP requests for this as much as possible instead of launching npm on server-side or using some js library code for that.
What I've found out is:
From http://registry.npmjs.org/package-name one could get all metadata for the specific package as well as list of available versions e.g. http://registry.npmjs.org/angular
From http://registry.npmjs.org/package-name/package-version I could get all metadata for the specific package of specific version e.g. http://registry.npmjs.org/angular/1.5.3
Now, what I'm struggling to find is how to obtain package.json of specific library and specific version because http://registry.npmjs.org/angular/1.5.3/package.json doesn't contain anything
Thanks a lot in advance for any hints!

Ok, it turns that list of dependencies is actually present in file with metadata for the whole package ( located in http://registry.npmjs.org/package-name ).
It's located in versions -> [version-id] -> dependencies, devDependencies and optionalDependencies properties.

Related

Advice for internal npm packages pulled into git repo

we're working through a setup at my work and I want to see if anyone has any advice/best practices for what we're doing here.
We have code in a git repo for our ui library that produces an npm package (in an internal private registry). That package then gets pulled into the git repos for each of the main products. The question is about versioning the package.
Because we're going from a parallel dev process (git) to linear package versions, which then gets pulled back into another parallel dev process (product git repos), there's an opportunity for code from the library to be accidentally released to production:
Change A is made to the library, produces v1.0
Change B is made to the library, produces v1.1
The library version in a product is updated to v1.1 to access Change B
Product change, and v1.1, is released; Change A in v1.0 is accidentally included
Does anyone have any advice, best practices, or alternate workflows we could keep in mind? The main thing is, we want the UI library stored in one repo but able to be pulled into multiple other repos.
Thank you!

Why some libraries in simple vanilla Js require NPM?

I am pretty new to js. And I am looking to learn js. Recently I came across one library called bounce.js which is animation library. Which require NPM to install but why? I am dont want to use NPM (or any packet Manager) they havent provided min.js file to direct import in scrpit tag?? Why??. Similarly for Tailwind it require NPM. And as NPM require it means I need vercel to deploy and all stuff.
2) As I use django I dont know how to install NPM modules in my templates.
Please help me clear out from this mess.
When all I can find is NPM based installation guides I like to search the library name followed by CDN which typically brings up some minified results. In your case I tried searching for bounce.js CDN which brought up lots of results including this one:
https://cdnjs.com/libraries/bounce.js/0.8.2
which points to
https://cdnjs.cloudflare.com/ajax/libs/bounce.js/0.8.2/bounce.min.js
You should be able to do some searching and find the CDN you wish to use. If you want the source JS to serve from your own server you can visit the .js link and right click and download (or copy and paste into your own file).
One of the advantages of using npm over a direct download is facilitating the integration into your workflow.
For instance, if you use a module bundler, the bundler will generate an "optimised", minified version for you: Getting rid of unused code for you (=> Tree shaking) reducing the size of your resulting code, solving some import issues, and more
NPM will also help you keep track of your imported library. You know if you use an up-to-date or outdated version. It will also inform you about
Eventual securities issues. And much more.
There are many, many advantages of using npm over direct download.

Using package.json for client side packages, that could be loaded dynamically in browser

I am thinking of extending the format of package.json to include dynamic package (plugin) loading on client side and I would like to understand whether this idea contradicts with npm vision or not. In other words I want to load a bunch of modules, that share common metadata, in browser runtime. Solutions like system.js and jspm are good for modules management, but what I seek is dynamic packages management on client side.
Speaking in details I would like to add a property like "myapp-clientRuntimeDependencies" that would allow to specify dependencies that would be loaded by browser instead of standard prepackaging (npm install->browserify-like solution).
package.json example:
{
name: "myapp-package",
version: "",
myapp-clientRuntimeDependencies: {
"myapp-plugin": "file:myapp-plugin",
"myapp-anotherplugin": "file:myapp-anotherplugin"
},
peerDependencies: {
"myapp-core": "1.0.0"
}
}
The question:
Does this idea contradict with "npm" and "package.json" vision? If yes then why?
Any feedback from npm community is very much appreciated.
References:
Extending package.json: http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging
EDIT:
The question was not formulated too well, the better way to ask this is:
What is the most standard way (e.g. handled by some existing tools, likely to be supported by npm) to specify run-time dependencies between 2 dynamically loaded front-end packages in package.json?
What is the most standard way to attach metadata in JSON format to front-end packages, that are loaded dynamically?
I wouldn't say that it conflicts with the vision of package.json, however it does seem to conflict a bit with how it's typically used. As you seem to be aware, package.json is normally used pre-runtime. In order to load something from package.json into your runtime, you'd have to load the package.json into your frontend code. If you're storing configurations that you don't want visible to frontend via a simple view source, this could definitely present a problem.
One thing that didn't quite click with me on this: you said that system.js and jspm are good for module management but that you were looking for package management. In the end, packages and modules tend to be synonymous, as a package becomes a module.
I may be misunderstanding what it is that you're looking for, but from what I can gather, I recommend you take a look at code-splitting...which is essentially creating separate js files that will be loaded dynamically based on what is needed instead of bundling all your javascript into a single file. Here's some docs on how to do this with webpack (I'm sure browserify does it as well).
If I understand correctly, your question is about using the package.json file to include your own app configuration. In the example you describe, you would use such configuration to let your app know which dependencies can be loaded at runtime.
There is really nothing preventing you from inserting your own fields in the package.json file, except for the risk of conflict with names that are used by npm for other meanings. But if you use a very specific name (like in your example), you should be safe enough. Actually, many lint and build tools have done so already. It is even explicitly written in the post you refer to:
If your tool needs metadata to make it work, put it in package.json. It would be rude to do this without asking, but we’re inviting you to do it, so go ahead. The registry is a schemaless store, so every field you add is on an equal footing to all the others, and we won’t strip out or complain about new fields (as long as they don’t conflict with existing ones).
But if you want to be even safer, you could resort to use a different file (like Bower did for example).

Twitter Bower file choosing

I was just playing about with Bower and got it to pull down jQuery 1.9.1 and Fancybox 2.1.4
That's great but for example, Fancybox pulls it's entire repo down including all the demo files and not just the actual files I need.
How should this situation be dealt with?
Neil
You have three options at the moment:
Bug the author about either properly using the ignore attribute of the component.json (or soon to be bower.json) or maintaining a separate repository just for bower like AngularJS does for example.
Register and maintain a component yourself.
Pull in just the file you need via HTTP like this:
"dependencies": {
"fancybox": "https://raw.github.com/fancyapps/fancyBox/master/source/jquery.fancybox.js"
}
Last last option comes with the drawbacks that neither dependency resolution nor multiple files will work. The best long-term solution is to lobby the author to correctly support bower.

How to create a custom framework package for WinJS (WinRT)

The project templates for Visual Studio 2012 contain a reference package with javascript, localization files and styles.
What I am wondering is how to build a custom reference package with my code, locales and styles. There is absolutely no information about this on the web, I tried referring to MSDN, but it did not give me any clue as to how I can do this. Please share any useful information that you may have about this.
It turns out Microsoft do have documentation on Extension SDKs.
Update:
I actually managed to get the reference/framework package. It all works really well except when opening Expression Blend with my package referenced. Notice the reference is there and I can actually see all components and their description but I'm still getting an error in the design surface. Here is what the error looks like (I know, it's very descriptive):
Update:
When trying to deploy an app referencing the framework package I have created I being given an error saying that it cannot find my framework but instead finds some framework with trailing symbols that I did not put there while packaging it. It appends the processor architecture as well as the package family name trailing symbols. Here's a screenshot:
The item you are looking at is a "Framework Package". While it is possible for you to generate a package that looks like a framework package (look at the appxmanifest.xml for the WinJS package in \Program Files\WindowsApps), you cannot get that package ingested into the store.
This is something that is not supported in Win8 -- you'll need to include the files you need in each package you build.

Categories