[Meta] Move all externally-developed files to core/vendor/{vendorname}/ directories

These files should also be ignored by testbot Coder reviews ... if someone can provide a complete list of files (or directories) to the related issue at http://drupal.org/node/1395712, it would be much appreciated. :)

Tagging.

This would also apply to everything in symfony now. (That's a lot of files.)

(Also, shouldn't this issue be filed against core?)

hi

my suggestion is that a @ignore in page level docblock stated before the @file could be used.

I doubt that it would create any bigger problems but perhaps someone with more knowledge of drupal than me knows.

I don't think there should be any changes needed to the API module. The API module doesn't care whether your files/doc comply with Drupal coding standards. It will display docs better if they do, but it really doesn't care. I also think that we *do* want these files (e.g., Symfony) displayed on api.drupal.org, so I hope that by putting an @ignore tag in the file, you don't mean that you want the API module to ignore them completely.

hey

with reading, talking with other people and thinking on the docbloc is coming from java from beginning

@ignore might not be allowed in a page-level doc
@ignore will only ignore the current block. i.e if two functions with docblock and the first one has @ignore the other one will still be public.
even if we today doesn't use the @ignore we might have that in the future, and the stuff above mentioned will then probably give us problem since our @ignore will mean two things suddenly.

So just as php doesn't use every @... that java does and probably have added some that java doesn't have.

I'm not sure and will be corrected but have a vague memory of a @extern tag in java, it sure doesn't exist for the php doc but no matter what that would actually make some sence to create a new tag for this.

edit; adding a note here.

After chatting some with @xjm I had missed that we in D8 have like whole directories with external files i.e symphony files. with tagging the files that would probably mean a lot of work.
Perhaps the solution for that would be to have a php-file in those directories with a proper name like "files.external" declaring a array $external[] = excludingfile.php..just a spontaneous idea. perhaps to complicated. if we do have this file in each directory we do not need tagging at all. but that doesn't mean it will be less of time to maintain that structure than tagging perhaps.

So... Let's go back to the original issue summary... What are we trying to do here, really?

It seems like we're trying to tell people "Leave these files alone". It seems to me that we are already doing that with the Symfony files, because they are in directory core/vendor, which should be enough of an indication.

But we have others, such as JQuery, that fall into that category of externally-developed files. So how about just having a policy that all 3rd-party "leave this alone" files should be in a "vendor" directory?

This issue partially duplicates #1473066: [Meta] Move third-party assets out of core/misc folder. Please exclude frontend code in this issue. Only discuss backend code.

My stance on this issue is:

/vendor is for PSR-0 namespaced code. If you have PSR-0 namespaced code, put it there. If your code isn't, then you don't.

Should actually be... core/vendor/{vendorname}/{packagename}

symfony/http-foundation

core/vendor/symfony/http-foundation

symfony/class-loader

core/vendor/symfony/class-loader

symfony/dependency-injection

core/vendor/symfony/dependency-injection

Vendor packages are simply third-party vendor packages. Doesn't matter if it's front-end or back-end. If they have depending resources shipped with them, then those resources should be retained.

PSR-0 is simply a standard in PHP for autoloading classes. Drupal's vendor folder is not restricted to just PSR-0 PHP files, as it's just a place for us to place un-changed third-party vendor packages.

aFarkas/html5shiv

core/vendor/aFarkas/html5shiv/html5shiv.js

pear/Archive_Tar

core/vendor/pear/Archive_Tar/Archive/Tar.php

@Rob Loach: Not everyone agrees with that definition.

So, let's get back to the basic problem, as stated in the issue summary, which is that it's difficult to tell, when you're in the core/misc directory for instance, which files are "DON'T TOUCH THIS -- THIRD PARTY" and which files can be edited, brought in line with our coding standards, etc. And because it's not obvious, people propose changes to these files on a regular basis.

The solution proposed to this problem would be to move everything 3rd-party to one location, core/vendor. sun objects in #12, because he thinks core/vendor should only be for PSR-0 namespaced code.

So... can sun or someone else come up with an alternate proposal of what to do to/with the other "don't touch this" files, so that coder and developers can all know they should not review/change the files, and perhaps so that the API module knows it should display them differently?

And as another example, the ArchiveTar stuff is in
core/lib/Drupal/Component/Archiver/ArchiveTar.php
which makes it look like it's part of Drupal's core component library, just judging by the directory names.

If for some reason it can't be in core/vendor (which I still don't really understand -- it is a PHP class, but whatever), at least it shouldn't have Drupal/Component in the directory name, and it should have vendor in the name if that is our standard for naming third-party stuff.

And maybe we need a misc/vendor subdirectory, to put the 3rd-party JavaScript libraries in?

To clarify: Although it's not 100%, I appreciate the current placement/differentiation -- you don't expect PHP code in /misc, only frontend stuff there. The code in /vendor is registered for autoloading, so I'd ideally like to have that clarity there (same clarity as /lib).

My perspective is: autoloaded vs. not-autoloaded, as well as backend-PHP vs. frontend-asset code.

Mixing all of these things together will end up in a dumping ground for everything and anything, without any kind of structure and organization.

I'm fine with introducing a separate space to differ between own frontend stuff and external frontend stuff to get ahold of /misc.

Putting jQuery into /vendor/jquery inherently means that the PHP namespace (!) is covered by a frontend library, so if jQuery happens to release a PHP toolkit to integrate with jQuery (unlikely, but just hypothetical example), then we are in trouble.

Same goes for PHP code that isn't really namespaced. We'd have to make up a namespace for that (potentially clashing with something else, diverging from upstream, etc) and/or introduce some custom autoloading support for that code, or don't autoload it at all... Either way, it's going to be a weird mixture of namespaced and not-namespaced code.

OK... So let's leave the JS code under misc, but put it in misc/vendor or something like that.

But on ArchiveTar, it's already in core/lib (which you say is part of psr-0), so why would it be so bad to put it in core/vendor instead?

@jhodgdon re: #20 - I cannot find the comment now, but I think it was @crell who said that ArchieveTar needed to be in core/lib... was it because of some small change made by Drupal? not sure ...

Putting jQuery into /vendor/jquery inherently means that the PHP namespace (!) is covered by a frontend library, so if jQuery happens to release a PHP toolkit to integrate with jQuery (unlikely, but just hypothetical example), then we are in trouble.

That's why we should move Symfony to vendor/{vendorname}/{packagename} directories as I defined in #13. The vendor folder is really meant for 3rd party packages which both Drupal developers and users should not touch. Whether the package is PSR-0 or not does not matter.

There is absolutely no reason why pear/archive_tar can't live in core/vendor/pear/archive_tar. We'd just have to work with Archive_Tar to fix whatever hacks we stuck it in. PSR-0 supports PEAR class naming. Register "Archive_Tar" at core/vendor/pear/archive_tar with the whole package there, and it will autoload.

I'd like to put JS back on the menu, please decide if js is allowed, otherwise it'll go in core/js/vendor: #1663622: Change directory structure for JavaScript files

This is done... External JavaScript could be discussed over at #1663622: Change directory structure for JavaScript files.

Whoops, meant fixed.

Drupal's ArchiveTar is actually an internal fork of Pear's Archive_Tar. Would be nice to switch to lootils/archiver for that, maybe we open a new discussion about that. Might have to reduce the dependency on PEAR though.

Matt also opened up: https://github.com/mattfarina/Lootils-UUID which cleans up the generation of UUIDs.

Updated to suggest a policy of moving all externally-developed files to core/vendor/ directories.

Updated issue summary.

Nope! I'm saying it's not external code because it's an internal fork of the Pear package, so it should not live in core/vendor. If we were to move it to core/vendor, we'd need to use the Pear package directly, or switch to something like lootils/archiver.

Actually, let's make this a meta issue for each component. Then we could switch each component individually rather than switching it all at once. Is there any other code that we could move to vendor packages?

Third-party JavaScript and CSS asset discussion should probably happen over at #1473066: [Meta] Move third-party assets out of core/misc folder.

RE #30 - sorry you are frustrated, but let's not just close this as "won't fix" just because you are frustrated.

RE #29 - I think ArchiveTar is the only item left on this issue, because the JavaScript code has been moved to a different issue as well.

Updated issue summary.

#1673246: Adopt Lootils\Archiver

Updated issue summary.

This has been done for third party scripts, they are in core/assets/vendor