Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add extra features #9

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

danielbayley
Copy link

Translate more values from package.json to info.plist, including support for environment variables.

const pify = require('pify');

const fsP = pify(fs);
const read = require('read-glob-promise');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

@danielbayley danielbayley Oct 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does that read in the contents in the same step? What are the advantages? (aside from it being yours 😉)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's battle tested in production and very fast. It being mine is not really the point here. I would always prefer a module I've used before and trust. No, it doesn't read the file contents, but that requires just a few characters extra characters, and it's kinda weird to mix those concerns.

Copy link
Author

@danielbayley danielbayley Oct 13, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I realised that since npm already copies the contents of the README to readme in package.json on install, that I could just grab it from there… which makes this much simpler and no need for an extra dependency anyway. I'll definitely check out globby in future though since it's a common need. 👍

Translate more values from package.json to info.plist, including support for environment variables.
data.description = pkg.description || '';
data.webaddress = pkg.homepage || pkg.author.url || '';
data.createdby = pkg.author.name || '';
data.description = data.description || pkg.description || '';
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Surely there must be a more elegant way to prevent overriding existing keys than this? CoffeeScript has ?= for example…

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why change the current behaviour? This is done on purpose, we always want the description from package.json to keep them in sync. It wouldn't make sense to set 2 different descriptions.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you mean, so you think description, createdby, and webaddress (version already is) should be forced from package.json?

@SamVerschueren
Copy link
Owner

Hi @danielbayley, first of all, thanks for the PR! I have to admit that I have not yet decided if I really want this. Maybe we should've discussed this first in a new issue. But now that we have the PR, let's discuss it here.

The name property for instance was first extracted from package.json but was removed in commit 52b50cb. The reason for that is when you are developing your workflow, you can call ./node_modules/.bin/alfred-link which will only symlink and not override these properties. Because then you will have to undo the automated changes from your info.plist before pushing to git which is annoying. But info.plist needs a name because Alfred will crash if not.

My other remark on this PR is, do we really need to be able to maintain all these properties in package.json? The reason these properties where chosen was because (1) they already are available in package.json by default so this deduplicates that information and (2) they can change over time.

So I have to think about this first before I decide. Feel free to throw in arguments in the discussion :).

@danielbayley
Copy link
Author

The name property for instance was first extracted from package.json but was removed in commit 52b50cb. The reason for that is when you are developing your workflow, you can call ./node_modules/.bin/alfred-link which will only symlink and not override these properties. Because then you will have to undo the automated changes from your info.plist before pushing to git which is annoying.

This PR doesn't affect that behaviour at all. It still works without even touching info.plist. Nothing gets overridden in info.plist unless left blank (although maybe some keys should be as mentioned above…)

It's handy to manage everything in one place (personally, I put everything in a project atom.cson and have it compile to package.json…)

Also, part of the idea was to try and standardise the bundleid (but without enforcing anything).

info.plist needs a name because Alfred will crash if not.

Strangely, it also seems to need <description> (even if just blank) incidentally…

Don't override any existing keys in info.plist
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.

None yet

3 participants