Vendor?

xen

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?

frissdiegurke

EDIT:
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/?

Original Post:

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 [email protected] # 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.

Some brainstorming:

NodeBB could provide equivalents to filter:scripts.get for styles and public directories. This would allow dynamically resolving the paths (require.resolve())
Best would be to use bower for frontend dependencies.
Is there a way to reliably trigger bower install via 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 install of plugins that contain a bower.json.
Or if NodeBB provides the hooks mentioned before plugins could call bower install within action:app.load so 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 bower as dependency.

yariplus

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.

julian

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

PitaJ

@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:

Beautiful, amiright?

julian

@pitaj Are you serious bower was the hot stuff not even 6 months ago, now it's outdated?

Crazy...

psychobunny

In order to switch we also need to take account hacks we've added to these vendor files. It's doable though

frissdiegurke

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

PitaJ

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

julian

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