Too much is never enough, eh?
We now return you to your regularly scheduled programming. 🖖 🐬 🐬
Why plugins from the public/vendor does not move in node_modules?
It seems to me that all of these plugins support npm.
So what is the reason that they are in a vendor?
After reading your post again it seems I answered to another question xD
The question I tried to answer: Why do plugins for NodeBB often have a vendor directory instead of using node_modules/?
You shouldn't depend on your package managers internal structure.
Relying on the path node_modules/ being existing and containing the expected is doing so.
For example if you do the following:
mkdir test cd test npm i emoji-parser # node_modules contains emoji-parser and wrench (the dependency for emoji-parser) # node_modules/emoji-parser/node_modules is not existing npm i firstname.lastname@example.org # any other semver range than emoji-parser uses within dependency definitions # node_modules contains emoji-parser and wrench (1.5.0) # node_modules/emoji-parser/node_modules contains wrench (the dependency version for emoji-parser)
So if you're developing
emoji-parser you cannot be sure where your dependency is located at.
And the above is only the structure of the current NPM version. It's not ensured to stay this way.
Since NodeBB requires you to state within plugin.json which files/directories to provide to public and which style-files to use etc. you'd need to know the directory they're located at.
So you have to do so by providing these files directly.
But I see your point and maybe future versions of NodeBB may provide alternative ways of injecting dependencies.
filter:scripts.getfor styles and public directories. This would allow dynamically resolving the paths (
bowerfor frontend dependencies.
bower installvia npm-scripts (e.g.
install)? Would require bower installed (within node_modules dir of plugin or globally, so just stating as npm-dependency wouldn't fit)
bower installof plugins that contain a bower.json.
action:app.loadso the files are ensured to exist when those hooks get called (If they're called after the
action:app.load, don't know the code-order). This way only the plugins would state
True to the name public/vendor, it is for files only used on the client, although some can be used server/node side, they are not at the moment, afaik.
@yariplus Correct, if they're in vendor, they're not used on the server.
Ideally, all of our client-side dependencies would be managed by bower, but that is difficult to do because:
So if one of us starts on it:
@julian Also, npm is replacing bower in almost every area, so you should use npm instead of bower for your client-side packages as well as your server-side ones.
For instance, here's a list of vendor plugins which are available from npm. It's all but I think three of the vendor subfolders:
@pitaj Are you serious bower was the hot stuff not even 6 months ago, now it's outdated?
In order to switch we also need to take account hacks we've added to these vendor files. It's doable though
@pitaj npm is used for frontend in many projects today, but I don't think this is a good thing to do.
Here are my notes:
And one by example (even if it might be a bit improbable for casual people):
If I'd be using npm for all dependencies I couldn't push a release without updating frontend first.
So I would still use bower rather than npm for my frontend dependencies (the most important point is to clearly separate front- and backend deps).
@frissdiegurke Sure, separation of concerns is nice and all, but in this case, I don't think it's that helpful
That last one is probably the most important. If you guys plan on using CommonJS on the frontend in the near future, you should use npm for all of your dependencies.
Yes, this is true, if we switch to browserify, then it couples nicely with npm.
That, and @frissdiegurke, npmv3 actually favours flattening the dependency tree if at all possible, so there's one more point in favour of npm