Master manifest file #101
Master manifest file #101
Conversation
stefanbuck
force-pushed
the
master-manifest-file
branch
11 times, most recently
from
ab33345
to
3dfa20f
Compare
|
Wow, I wasn't expecting so much effort to go into generating the manifest files, but it looks like there's some other changes here too. I'm wondering if we really need gulp and all the reorganization, though. For example, we could generate "build-chrome-manifest": "json -e 'delete this.applications' < firefox/manifest.json > chrome/manifest.json",Likewise, the "pack-repo": "mkdir -p out && zip --recurse-paths out/octolinker-repository-$npm_package_version.zip * --exclude dist/\\* out/\\* node_modules/\\*",What do you think? |
|
Mhhh to be honest, I'm a bit prejudiced, as I worked a couple of hours to get it working 😄 I see you point and in general I totally agree, but maybe there is some good reason to use gulp – let me think ... |
stefanbuck
force-pushed
the
master-manifest-file
branch
from
3dfa20f
to
6c3fc8a
Compare
|
The firefox mainfest.json needs an additional |
|
Oh, I definitely understand not wanting to let your work go to waste 😄 I certainly have no problem with using gulp, but it just struck me as overkill. Nice catch on the "build-chrome-manifest": "json -e 'delete this.applications; this.permissions.shift()' < firefox/manifest.json > chrome/manifest.json",To tie in what I was saying about the package.json version in #103 (comment), here's a script that copies the "update-firefox-manifest": "json -I -f firefox/manifest.json -e \"this.version = '`json version < package.json`'\"", |
|
I'm gonna close this in favor of #107 |
Resolves OctoLinker#156 It turns out that the only thing preventing this from working (other than permissions) is determining the path associated with the Blob. Before, the path was undefined, so the Blob was not initialized properly. With this change, the path will be set to the filename entered into the gist. Assuming that that the filename is set to something reasonable, either the filename-based language detection or the github-based language detection will work correctly (at least, for non-relative links). Here's a test page: https://gist.github.com/josephfrazier/113827963013e98c6196db51cd889c39 --- Note that we may want to change the manifest.json `permissions` handling at https://github.com/OctoLinker/browser-extension/blob/ec499e065424b5204885624a297ab463c99fa8ab/package.json#L17 See here for prior discussion: OctoLinker#101 (comment)
* Add gist support Resolves #156 It turns out that the only thing preventing this from working (other than permissions) is determining the path associated with the Blob. Before, the path was undefined, so the Blob was not initialized properly. With this change, the path will be set to the filename entered into the gist. Assuming that that the filename is set to something reasonable, either the filename-based language detection or the github-based language detection will work correctly (at least, for non-relative links). Here's a test page: https://gist.github.com/josephfrazier/113827963013e98c6196db51cd889c39 --- Note that we may want to change the manifest.json `permissions` handling at https://github.com/OctoLinker/browser-extension/blob/ec499e065424b5204885624a297ab463c99fa8ab/package.json#L17 See here for prior discussion: #101 (comment) * blob-reader: add test for gist blob path
Work in progress and branched off from #100
Based on the comment #100 (comment) this PR adds gulp which allows us to extend the manifest file with additional information.
New commits on top of #100 are