Make the plugin compatible with Snowpack v3.x

[AWolf81]

As mentioned in issue #5. The current web-ext plugin only works on 2.x API.

To make it compatible the following point require changes:

• [x] config.installOptions.cwd replace with config.root
• [x] env from config.installOptions.env to config.packageOptions.env
• [ ] Fix manifest.json copy from root folder to build - not sure why this is failing

I'm trying to make it compatible v2.x and v3.x. I think that should be possible.

[dleetr]

Would be looking to tackle this as I am trying to set up a smooth pipeline for building out a web extension. Are you still interested in maintaining this plugin @AWolf81?

[AWolf81]

Yes, sounds great. I'd be happy to review your PR and merge it. I haven't worked on it for a long time.

[dleetr]

I was trying to specify a local dependency using your example repo https://github.com/AWolf81/snowpack-chrome-preact-popup-demo And changing the package.json entry for the plugin to the following: "snowpack-plugin-web-ext": "file:../snowpack-plugin-web-ext", But when I try to run npm run start the error shows Error: Cannot find module 'snowpack-plugin-web-ext' I've tried building the package and changing the main property like this "main":"pkg/dist-src/", in the plugin package.json but then I get the error SyntaxError: Cannot use import statement outside a module.

I'd like to not have to push every time just to get a testing pipeline going, so I was wondering how exactly this can be set up? The fact that I get the second error leads me to believe the path is correct, so I think I need some configuration change, and not a path fix.

EDIT: Immediately after asking this I realized that I can use the develop-package branch as a template for setting up a local file build. I will try later today and see if I can figure out how to generate a build in that structure from the main branch since the other branch seems like it may be lacking some of the commits.

[AWolf81]

Yes, that's right. develop branch is behind the main branch. I don't remember my workflow that I used two years ago. Maybe I did something with the develop-package but I'm not sure.

For me the development is working like this:

• Run npm build to get a new extension build.
• npm install in the demo after you added the local dependency (just needed during initial setup)
• Finally, run the example with npm start - linked to the local package with ""snowpack-plugin-web-ext": "file:../snowpack-plugin-web-ext/pkg"

Note: The pkg folder at the dependency in the demo is important. With this, you don't need the main key in the extension package.json because npm is using the package.json from the build result.

(I couldn't get it to work with the dist-src. I got the same error with the import statement outside a module. I think dist-node should be used here - see package.json of the build result from the extension.)

[dleetr]

I've created an issue in snowpack discussions here The root cause of the manifest copy seems to be that snowpack at some point made a change where it will clean the build directory after we have written to it. I've tried to move the copy to occur later in the lifecycle but haven't been able to tell snowpack to not clean it from the plugin side.

As a work around, use buildOptions.clean in the user's snowpack config to just stop snowpack from cleaning. Changes still need to be made to make a fallback, but it is a minor rechanging of properties that I can submit a pr for. But what I would like to find is a fix that doesn't require disabling the cleaning process.

  buildOptions: {
    metaUrlPath: "snowpack_meta", // chrome issue with __snowpack__ because _ is reserved for system
    clean: false, // TODO: enable this again if we can't fix the plugin
    /* ... */
  }