Additional files to be added to .distignore

[dominic-ks]

There are some additional files and folders that don't need to go out to WordPress.org and should be added to .distignore:

• tests
• .gitattributes
• FUNDING.yml
• phpunit.xml.dist

[sun]

The GitHub Action actually failed: https://github.com/usefulteam/jwt-auth/actions/runs/8992257107/job/24701674019

Looking at the log, I think we can additionally exclude some Composer libraries:

vendor/guzzlehttp
vendor/doctrine
vendor/nikic
vendor/phar-io
vendor/phpunit

…though that being said – these libraries are explicitly defined in require-dev, so they should not be installed in the release packaging process:

jwt-auth/composer.json

Lines 21 to 27 in f99ca5a

	"require-dev": {
	"php": ">=7.4",
	"phpunit/phpunit": "^9.5",
	"guzzlehttp/guzzle": "^7.8.1",
	"ext-json": "*",
	"ext-curl": "*"
	},

So it looks like the dev: no option does not do what it is supposed to do:

jwt-auth/.github/workflows/deploy.yml

Lines 12 to 14 in f99ca5a

	- uses: php-actions/composer@v6
	with:
	dev: no

🤔 although it is documented that way: https://github.com/php-actions/composer?tab=readme-ov-file#passing-arguments

[dominic-ks]

@sun Yep, so I did tweak a few things as I was doing this last night as I just wanted to squash some issues as I went.

So the dev: no does work, I added that afterwards to reattempt the deployment, and it does do what it is meant to and only includes the non-dev packages.

I have a feeling that the reason for #120 is that initially the dev: no flag was missing, and so on WordPress.org svn the 3.0.2 tag does actually contain the dev dependencies, and the next fresh deploy with a new tag will likely work without issues, therefore, I do think we just need to exclude the extra files I listed here.

As a side note, until now, the plugin has stated the current stable version of the plugin is trunk, which is advised against in the docs, however, in this case it has been fortunate, since it means, although those files are present in the 3.0.2 tag on svn, they are not being downloaded, as wp will download from trunk.

Again, from the next tag, I think this will work cleanly, and the WordPress deploy action will automatically update the current stable branch to the name of the tag.

One further aside, is it appears that the current package-lock.json file has some issues that the deployment was complaining about, and I think needs to be regenerated.

[sun]

Ah that makes sense – so we can just exclude the files you listed originally.

Not sure about trunk though. The "New tag" action was actually updating the files in trunk - also visible in Subversion: https://plugins.trac.wordpress.org/browser/jwt-auth/#trunk

Where can you configure which folder wp.org is using for downloading the release?

[dominic-ks]

Yes, the deployment to WordPress action will do these things:

• Copy the release files to trunk
• Copy the release files to a new folder tags/<tag-name>
• Update the plugin version to the tag name in readme.txt, where is says "Stable tag:"

I think you still need to set the plugin version in the jwt-auth.php file manually, could be wrong on that though...

The final point above wasn't done last night as the action failed, so I changed it on GitHub manually, but the version on svn right now is still pointing to trunk.

It's the "Stable tag:" that determines which folder is used for plugin installs in WP.

[sun]

This seems to be a nice quick fix we could include in the next release.