Is bin/update-configs.sh necessary?

[iandunn]

We could instead call tools with --config=vendor/.../eslint.js, etc. That way everything stays DRY and consistent without any maintenance.

We could also symlink if they don't.

Some tools might support having a local "override" file, ala phpunit.xml.dist and phpunit.xml. Some also support @extend / import-ing another file.

[coreymckrill]

I'm open to improvements on this. There are two reasons for copying these files into the root:

• Even though you can specify locations for these with command line stuff like --config=vendor/.../eslint.js mentioned above, some IDEs will only use them if they are in the project root (according to @ryelle)
• Copying the phpcs.xml file allows us to dynamically insert the text domain. The same method could possibly be useful for other configs we add in the future too.

[iandunn]

some IDEs will only use them if they are in the project root

IIRC, that was only the case for prettier + Atom. IMO a simpler solution could be to symlink that specific file to vendor/

I'd lean towards letting individual devs do that locally, rather that making it part of repo-tools, because it's specific to one IDE that (AFAIK) most of us don't use. I don't feel strongly on that part, though. We could also just symlink all of them.

dynamically insert the text domain

That seems like a good use case for shared config being in phpcs.xml.dist, and site-specific config being in phpcs.xml.

[ryelle]

I can't say it's only Atom, it might be others too. For ease of setup (not having to manage symlinks), it would be nice to keep the update-configs command around, though if the scripts are set up with --config=vendor/.../eslint.js, you could just never run update-configs.

[iandunn]

For ease of setup (not having to manage symlinks), it would be nice to keep the update-configs command around

What makes copying easier? I was assuming we'd automate symlinks in the env:setup script.

if the scripts are set up with --config=vendor/.../eslint.js, you could just never run update-configs.

So we'd have both /eslint.js and /vendor/.../eslint.js, but /eslint.js would only be for IDEs?

It seems like that'd be confusing, like when making changes to /eslint.js dosen't work, because they actually need to be editing /vendor/.../eslint.js.

[ryelle]

I've just had trouble with symlinks in the past - something happens and the destination goes missing, or for some reason a program won't read a symlink, or the symlink doesn't exist in the container … I suppose if there was a way to reset the symlinks just in case, maybe that would be fine? I'd still prefer real files + make it optional, though.

It seems like that'd be confusing, like when making changes to /eslint.js dosen't work, because they actually need to be editing /vendor/.../eslint.js.

I think that's a positive though, it would ensure that any changes to configs happen at the wporg-repo-tools level. Right now we have slightly different eslint configs across our projects, since changes have been made as the projects evolve. Once a change is made in vendor…, running update-configs again should sync those local files.

[iandunn]

the destination goes missing

I can't remember that ever happening to me, but no objection to a reset script

a program won't read a symlink

That's been pretty rare in my experience, but if we ran into it in practice then we could always use a hard link instead. Then the program wouldn't be able to tell the difference

the symlink doesn't exist in the container

Are you referring to the path differences? I don't think that'd be a problem if we used a relative link

ensure that any changes to configs happen at the wporg-repo-tools level

The copies are already git-ignored, so don't we have that either way?

overall, it still feels like unnecessary complexity to me, but i'm happy to disagree-and-commit if y'all still prefer it. just adding the --config=vendor/.../eslint.js bits to package.json WFM, since i can delete the copies locally

[coreymckrill]

That seems like a good use case for shared config being in phpcs.xml.dist, and site-specific config being in phpcs.xml.

Do they actually merge if you have both? I was under the impression that it will prefer phpcs.xml over phpcs.xml.dist if it exists.

[iandunn]

Er, you're right. I think the PHPCS way of doing it would be to have repo-tools define a wordpress.org standard. Then each individual repo would have a phpcs.xml.dist that would import the standard, and override anything that was specific to the project.