Considering expanding the structure of package.json to incorporate dynamic package (plugin) loading on the client side. I am curious about how this idea aligns with the vision of npm. Essentially, I am interested in loading multiple modules with shared metadata during browser runtime, as opposed to traditional prepackaging methods like npm install -> browserify.
To delve deeper, I am contemplating adding a property such as "myapp-clientRuntimeDependencies" to specify dependencies that will be loaded by the browser rather than through standard prepackaging procedures.
Example package.json:
{
name: "myapp-package",
version: "",
myapp-clientRuntimeDependencies: {
"myapp-plugin": "file:myapp-plugin",
"myapp-anotherplugin": "file:myapp-anotherplugin"
},
peerDependencies: {
"myapp-core": "1.0.0"
}
}
The query: Does this concept conflict with the vision of "npm" and "package.json"? If so, what are the reasons behind it?
I welcome any insights from the npm community.
References: Extending package.json:
EDIT:
The initial question may not have been articulated clearly. A better way to phrase it would be:
What is regarded as the most conventional approach (e.g., supported by existing tools, likely endorsed by npm) for defining run-time dependencies between two dynamically loaded front-end packages in package.json?
How can metadata in JSON format be best attached to dynamically loaded front-end packages?