Useful tool: PKPass Validator

[socsieng]

I came across the PKPass Validator while trying to troubleshoot issues with my pass and it helped save me a huge amount of time.

I'm posting this here for anyone who may be struggling to troubleshoot issues with their own passes.

[alexandercerutti]

That's a very interesting tool. I had in mind to create something like that, maybe a CLI or maybe integrating it inside https://pkvd.app. But that was an idea behind the back of my brain, eh eh 😄

[alexandercerutti]

Yes, I wanted to create a tool that could give clear feedback about what was happening but never had enough time or clear ideas.

The issue is that I don't think we are able to distinct development mode from production mode. If something like webpack is being used, we could have used something like a DefinePlugin, but we say that who is using passkit-generator, is also using Webpack or another bundler.

Do you have any suggestions about this specific topic?

P.s. thank you for PKVD! It took me a year to create it (and I'm still not very satisfied of it 😁).

[socsieng]

A Webpack/bundler plugin seems like overkill to me.

I think there's potentially a couple of ways to distinguish between dev and prod.

1. Make use of process.env.NODE_ENV to distinguish between environments, and
2. Explicit option in the API e.g. PKPass.from({ /* .. */, mode: 'debug' })

[alexandercerutti]

No, I meant a bundler in the projects that use passkit-generator.

Mmm, we might think to use process.env, but I have to understand better how can it be used. I mean, I currently print warnings or throw errors if something is wrong (e.g. missing icons, at least one should be available, when trying to export the pass). So, I have to understand if it might be worth performing a check when importing the certificates or when exporting the pass or... at all?

My main doubt is: where should passkit-generator stop and where should something else come in?

I think I'm going to exclude the flag "debug", because I should insert it also inside the constructor, and in constructor I should add another parameter... so I'm not very convinced.

[socsieng]

My main doubt is: where should passkit-generator stop and where should something else come in?

I was testing out the API using something like node create-pass.js. Errors/warnings about certificates, missing attributes, etc. would have helped my to correct it immediately without having search for answers about what may/may not be the problem.

Ideally, issues would be logged somewhere by Apple (maybe they are - I couldn't find it), but because it isn't, I think it is even more important that these issues are identified when the package is created.

[alexandercerutti]

Mmh, I agree with you, but at the same time, I would like to keep the size of passkit-generator as a package, small, and for every context.
Apple, actually, has a way to debug the pass, but you are required to have a Mac (wasn't that obvious? ahah). I wrote a guide in the wiki about debugging: https://github.com/alexandercerutti/passkit-generator/wiki/Self-help

Since many messages are shown there, even if sometimes they might be a bit cryptic, you can usually debug your pass from there.
It is not the same if you don't have a Mac. So, a tool like the one you linked or maybe a CLI version of it, is good: it is external from passkit-generator and independent. Passkit-generator can be used to literally generate only and you can check what you are doing the wrong step by step with the help of both, but by keeping them separate and, moreover, one for also production and the other only for development.

Sometimes I think that would be cool to remove anything about validation and errors from passkit-generator and add something like a plugin for optional validation... but sometimes I also think that might not be a good idea.

I'm not very sure about all of this, but I'll think more about it.