{"action":"created","issue":{"url":"https://api.github.com/repos/meteor/meteor/issues/3681","labels_url":"https://api.github.com/repos/meteor/meteor/issues/3681/labels{/name}","comments_url":"https://api.github.com/repos/meteor/meteor/issues/3681/comments","events_url":"https://api.github.com/repos/meteor/meteor/issues/3681/events","html_url":"https://github.com/meteor/meteor/issues/3681","id":56972807,"number":3681,"title":"Easier adding of existing libraries to packages","user":{"login":"mitar","id":585279,"avatar_url":"https://avatars.githubusercontent.com/u/585279?v=3","gravatar_id":"","url":"https://api.github.com/users/mitar","html_url":"https://github.com/mitar","followers_url":"https://api.github.com/users/mitar/followers","following_url":"https://api.github.com/users/mitar/following{/other_user}","gists_url":"https://api.github.com/users/mitar/gists{/gist_id}","starred_url":"https://api.github.com/users/mitar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mitar/subscriptions","organizations_url":"https://api.github.com/users/mitar/orgs","repos_url":"https://api.github.com/users/mitar/repos","events_url":"https://api.github.com/users/mitar/events{/privacy}","received_events_url":"https://api.github.com/users/mitar/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-02-08T23:09:14Z","updated_at":"2015-02-10T23:52:40Z","closed_at":null,"body":"I know there was a lot of discussion about this already done, but I find this really the worst part of Meteor. Having to modify upstream code so that one can use a global symbol defined in a library is really painful. Meteor tries to be smart and differs between, at the top level:\r\n\r\n```\r\nvar FileScope = {};\r\n```\r\n\r\nAnd:\r\n\r\n```\r\nPackageScope = {};\r\n```\r\n\r\nThe first becomes file scoped, while the second package scoped (and potentially exported). I think this is an interesting approach, but it fails for 3rd party libraries, because for them both syntaxes are the same and when they are defining global (browser) scope, they almost always use the first scope. I am suggesting a simple extension to current packaging:\r\n\r\n```\r\napi.addFiles([\r\n  'dist/library.js'\r\n], 'client', {packageScope: ['FileScope']});\r\n```\r\n\r\nThis would make variable `FileScope` behave like package scope, no matter if it was defined `var FileScope`. This would address 99% of issues I had encountered while trying to package 3rd party libraries."},"comment":{"url":"https://api.github.com/repos/meteor/meteor/issues/comments/73809926","html_url":"https://github.com/meteor/meteor/issues/3681#issuecomment-73809926","issue_url":"https://api.github.com/repos/meteor/meteor/issues/3681","id":73809926,"user":{"login":"glasser","id":16724,"avatar_url":"https://avatars.githubusercontent.com/u/16724?v=3","gravatar_id":"","url":"https://api.github.com/users/glasser","html_url":"https://github.com/glasser","followers_url":"https://api.github.com/users/glasser/followers","following_url":"https://api.github.com/users/glasser/following{/other_user}","gists_url":"https://api.github.com/users/glasser/gists{/gist_id}","starred_url":"https://api.github.com/users/glasser/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/glasser/subscriptions","organizations_url":"https://api.github.com/users/glasser/orgs","repos_url":"https://api.github.com/users/glasser/repos","events_url":"https://api.github.com/users/glasser/events{/privacy}","received_events_url":"https://api.github.com/users/glasser/received_events","type":"User","site_admin":false},"created_at":"2015-02-10T23:52:40Z","updated_at":"2015-02-10T23:52:40Z","body":"Apparently it's not documented (I thought it was at some point) but isn't this what the `{ bare: true }` option to `api.addFiles` does?  (And the `client/compatibility` directory in an app, which is documented.)"}}