Skip to content

Conversation

@szepeviktor
Copy link
Contributor

@szepeviktor szepeviktor commented Jan 29, 2020

@mnelson4 Here you go! :)

Closes #44

@szepeviktor
Copy link
Contributor Author

szepeviktor commented Jan 29, 2020

Do you have capacity to follow WPCS or PSR-12?
The first big step could be made by running vendor/bin/phpcbf

If yes please remove || true

@szepeviktor
Copy link
Contributor Author

Also PHPStan level 0 is for broken software, 2 or 4 looks normal :)

@szepeviktor
Copy link
Contributor Author

szepeviktor commented Jan 30, 2020

Done. All green 🍏

If would exclude these files from the ZIP then .gitattributes should be edited.

@mnelson4
Copy link
Owner

Awesome. But I think I'd rather use PSR-12 coding standards rather the WP ones (I'm more accustomed to those I think). Is that an easy change?

@szepeviktor
Copy link
Contributor Author

szepeviktor commented Jan 30, 2020

Done.

Coding style is a habit of Mike :)

@mnelson4
Copy link
Owner

Yeah those coding standards look more like what I'm already doing, great.

I'd like to avoid accidentally committing all these composer files to the git repo, and the WordPress SVN repo.
I was going to add a .gitignore file like this:

vendor/
!vendor/autoloader.php
!vendor/composer

so the git repo will ignore everything in the vendor folder except composer's autoloader, but then I noticed the files in vendor/composer get modified when I run composer install and I think I'd rather not commit those changes by accident. What would you recommend?

And for the SVN repo, it will be a bit of a pain to SVN ignore all the files (and I'm sure I'll forget to manually remove them). How would you suggest preventing accidentally committing the files in vendor to the SVN repo? I suppose I'll need a build process or something like WordPress/wp-lazy-loading#13

@szepeviktor
Copy link
Contributor Author

szepeviktor commented Jan 30, 2020

I'll need a build process

Yes!

  1. Keep only source code in this repo, no generated code
  2. Have an automatic build process
  3. And a manual CI action - e.g. 10up/action-wordpress-plugin-deploy - to automatically deploy to WP.org

@szepeviktor
Copy link
Contributor Author

When you release your plugin you may upload the built ZIP to GitHub releases.

@mnelson4
Copy link
Owner

I think I’m going to wang to use Gulp for building, as I’m hoping to add Freemius integration and there’s a gulp-Freemius package https://freemius.com/help/documentation/selling-with-freemius/deployment/

@szepeviktor
Copy link
Contributor Author

As far as I know the only thing to build/generate is the Composer autoloader.

@mnelson4
Copy link
Owner

Oh right— the other built things are just necessary for running those automated tests which Travis is already doing, so I don’t even need to run those locally...

@mnelson4 mnelson4 merged commit eab5d0a into mnelson4:master Jan 31, 2020
@szepeviktor szepeviktor deleted the patch-1 branch January 31, 2020 11:49
@mnelson4
Copy link
Owner

mnelson4 commented Feb 4, 2020

FYI this got an honourable mention in my monthly transparency report: https://cmljnelson.blog/2020/02/04/print-my-blog-transparency-report-january-2020/#autoloading-and-code-cleanup-with-viktor-svepe

@szepeviktor
Copy link
Contributor Author

Thank you Mike.

@szepeviktor
Copy link
Contributor Author

szepeviktor commented Feb 4, 2020

@mnelson4 Could you put a hotfix on my name?

kép

@mnelson4
Copy link
Owner

mnelson4 commented Feb 5, 2020

hotfix released! My apologies... admittedly a lot of my blogging has recently happened at 5am...😝

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 basic tests

2 participants