@baris Thank you!!!! 👍👍
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-parseryou 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.
- NodeBB could provide equivalents to
filter:scripts.getfor styles and public directories. This would allow dynamically resolving the paths (
- Best would be to use
bowerfor frontend dependencies.
- Is there a way to reliably trigger
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)
- If there is not maybe NodeBB could state bower-dependency and ensure
bower installof plugins that contain a bower.json.
- Or if NodeBB provides the hooks mentioned before plugins could call
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
- NodeBB could provide equivalents to
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:
- None of us want to leave it half-implemented
- It would take many hours to map out our current library calls and replace them in bower
- It might break plugins (!!)
So if one of us starts on it:
- It would be in a branch
- When it gets close, the next release of NodeBB would be automatically another minor revision.
@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:
- ace editor
- most of the jquery plugins
@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:
- bower doesn't force you to use a module-based structure (this might be considered as con, but as long you can use a module-based structure I don't do so)
- using bower AND npm has the advantage of separating which modules are used for front- and which for backend
- bower has flat structure and doesn't allow different versions of the same package
- bower features git-operations rather than central repository
- side-effect: you can easily fork a project without the need to think of a new id for npm and do your changes
And one by example (even if it might be a bit improbable for casual people):
- I use xyz as dependency in front- and backend
- A security issue has been noted within xyz that got fixed alongside with breaking changes
- Now I can update backend first for security reasons and push a fast release with updated xyz in backend but not in frontend
- At last I have all the time it needs to update within frontend
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
- The frontend and backend of NodeBB are inherently coupled due to it being a single-page application with server rendering
- The community at large is moving away from bower
- Fewer build steps / dependency headache = easier for end users
- Fewer configuration files to maintain
- If you chose to move to Browserify or Webpack, you must use npm anyways
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