Linter Guidance
Permalink
The Linter sandbox is a great idea though some guidance might be nice.
Specifically we've found that we're rejected if the zip contains the __MACOSX hidden folder, so users will have to zip up via 3rd party tool or command line on a Mac
Big issue we can't get past is that our icon.png images are rejected, both package level and block level. We've never previously had an issue here. What are the exact requirements for these images now? We're looking at ours vs a core block icon.png and are struggling to identify differences.
This is the linter feedback, package/blocknames removed.
visibility_test
File: ******/blocks/******/._icon.png
"._icon.png"
File: ******/._icon.png
"._icon.png"
Any guidance on the rules underpinning Linter would be appreciated.
Specifically we've found that we're rejected if the zip contains the __MACOSX hidden folder, so users will have to zip up via 3rd party tool or command line on a Mac
Big issue we can't get past is that our icon.png images are rejected, both package level and block level. We've never previously had an issue here. What are the exact requirements for these images now? We're looking at ours vs a core block icon.png and are struggling to identify differences.
This is the linter feedback, package/blocknames removed.
visibility_test
File: ******/blocks/******/._icon.png
"._icon.png"
File: ******/._icon.png
"._icon.png"
Any guidance on the rules underpinning Linter would be appreciated.
Odd that. Am using an external tool to zip and can't see those files. And if I drop in a core block icon.png one of the errors goes away. Revert it back to our icon.png and the error comes back.
Maybe although you are using the external zipper, the '.' files are still getting copied with the icon.png files and your mac is hiding the ._icon.png files when you view the zip.
To double check, copy the zip and browse on a PC with 'show hidden files' enabled.
To double check, copy the zip and browse on a PC with 'show hidden files' enabled.
PS, could it be you mac is then automatically adding the '._icon.png' files to the zip when you view it, ie. after you have created it?
Cheers John. I think, we're ok again now, located the files. Don't know how they got in there, but it's sorted.
Does anybody have a "packager"?
For my own use, I've been thinking of writing a simple tool that will zip up a package and remove all .* stuff, including git, and call the file name based on the version number in the controller.
I'm just below the threshold where the (minimal) effort would make sense, though.
For my own use, I've been thinking of writing a simple tool that will zip up a package and remove all .* stuff, including git, and call the file name based on the version number in the controller.
I'm just below the threshold where the (minimal) effort would make sense, though.
I wish I had built one 3 years ago...
Old thread, but I use Yemuzip on my Mac. Takes out all the crap.
http://www.yellowmug.com/yemuzip/...
http://www.yellowmug.com/yemuzip/...
packagename/icon.png
packagename/blocks/blockname/icon.png
The errors you note are for files starting "._icon.png", so are files that are not supposed to be in the distribution.
There has been some discussion in the past on creating a clean zip from a mac. I think they generally concluded as you have, that a 3rd party zip utility is needed to keep the mac system files out of it.