CODEWITHSUNDEEP
javascriptjsonbrowsernpmpackage
lextiz
lextiz

Reputation: 318

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?

Upvotes: 0

Views: 708

Answers (2)

Mike S.
Mike S.

Reputation: 951

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).

Upvotes: 1

ghybs
ghybs

Reputation: 53290

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).

Upvotes: 0

Related Questions