Giters

mozilla / libdweb

Extension containing an experimental libdweb APIs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Restructure demos

Gozala opened this issue · comments

commented

Currently our demo web-extensions are under ./demo/ directory and reference experimental APIs outside of the directory as seen here

libdweb/demo/protocol/manifest.json

Lines 8 to 23 in 9680f25

"experiment_apis": {
"protocol": {
"schema": "../../src/protocol/protocol.json",
"child": {
"scopes": ["addon_child"],
"paths": [["protocol"]],
"script": "../../src/protocol/client.js"
},
"parent": {
"events": ["startup"],
"scopes": ["addon_parent"],
"paths": [["protocol"]],
"script": "../../src/protocol/host.js"
}
}
},

This not great because:

  1. web-ext build produces corrupts extensions as it omits files from outside of the directory.
  2. manifest.json can't be just copied. Developer needs to figure out how:
    1. include libdweb in first place
    2. update paths to reflect new location
  3. After bringing up the fact that web-ext does not include files from outside to WebExtensions team they've filled a bug to disallow referencing modules from outside the directory.

I see following options going forward:

  1. Break out demo web-extensions into separate packages that could install libdweb via npm / yarn. That way they'd reference libdweb APIs under ./node_modules/libdweb/...

    • I do not know if web-ext build work out in that case. It will either omit node_modules all together or it will include all of it which isn't ideal either.
    • package.json of individual demo would probably have to use refer to git dependency or we would need to publish updates. I don't know if publishing updates would make much sense.
    • It probably would make more sense to move individual API into separate repo / package so that web-extension will install ones that it needs rather than whole bundle. That would sadly make sharing gecko typedefs more complicated.

  2. WebExtension team suggested using symlinks.

    • That would not really work on windows would it ?
    • I'm pretty sure (although have not tested it) that web-ext build would still not make a web-extension that would work.

  3. We could create separate manifest.json files in the root, like protocol.manifest.json and tcp.manfiest.json etc... and just copy content of demo being run into manifest.json before running web-ext run.

    • In that case web-ext bulid would likely produce extension containing all of the stuff which is not ideal.

I'm leaning towards first option as that would allow anyone to just fork the repo and build from there. Unfortunately it would require more work on our side though.

commented

As it turns out web-ext ignores node_modules and as of writing there is no way to opt out of it (see mozilla/web-ext#1347 I am trying to land a change to web-ext (see mozilla/web-ext#1348) to allow optional inclusion of specific packages from node_modules so that libdweb could be installed via npm.

It might make sense to add web-ext dep from my fork in the meantime to unlock this.

commented

@soapdog suggested use of symlinks instead to keep toolchain as simple as possible. I don't know if doing that is really going to help as we have npm / yarn dependency regardless. I am also hesitant of using symlinks as that will undermine windows users.

commented

I would like to migrate demos to https://github.com/libdweb org as forks of https://github.com/libdweb/template