how to use env variables in SW for Workbox 5

[novaknole]

Library Affected:
const { InjectManifest } = require('workbox-webpack-plugin');.

Browser & Platform:

• Google Chrome Latest.*

Issue or Feature Request Description:

I am using workbox-webpack-plugin 5.0.0

Question 1)

Now, In my project, I have a index.js file looking like this:

module.exports = Object.freeze({
    app: require('./app'),
    company: require('./company'),
    api: require('./api'),
    locales: require('./locales'),
    services: require('./services'),
});

and let's take a look of one of the files app: require('./app')

module.exports = {
    url: process.env.API_URL
};

what I now need is to use those variables in my service worker file. I can't import index.js file since I don't copy/paste it via copy-webpack-plugin. What other ideas do you have on your mind, Jeff ? I tried:

webpackCompilationPlugins:[
                new DotEnvWebpack({ systemvars: true })
            ],

but when I console process.env in service-worker, It's an empty object.

What do I do ? @jeffposnick

Question 2)

In my sw.js, I have this:

importScripts('/js/indexedDb/idb.min.js')
importScripts('/js/indexedDb/utility.js')

I am thinking about a new way of including these in my sw.js. idb.min.js is already compiled which is great, but my utility.js is not compiled which makes me worried. Is there any way I don't import those scripts, but somehow by using injectmanifest plugin, i can still compile and include it somehow in my final bundled sw.js?

[philipwalton]

My understanding is that webpack child compilers (which the workbox-webpack-plugin uses) don't inherit the plugins specified in the main config, which means that any plugins you use there will not be applied to your final service worker file.

@jeffposnick, can you confirm? If so, would it be possible to add an option to workbox-webpack-plugin to pass in child-compiler config overrides?

@novaknole, another option you can do now would be to compile your service worker separately from the rest of your app. There's some guidance on how to do that here: https://developers.google.com/web/tools/workbox/guides/using-bundlers

[novaknole]

I have injectManifest working for other cases. i can't just change the whole logic of bundling service worker. There should be some way to somehow pass env variables to service worker through InjectManifest. Nobody has needed this before?

@jeffposnick shoot some ideas .

Thanks both of you.

[jeffposnick]

Regarding question 1, as soon as #2400 is deployed in the next Workbox release, using webpackCompilationPlugins should work.

(I am working on fixes for #2383 and #2399 that I'd also like to ship in the next release, but if that ends up taking too long, maybe we could ship v5.0.1 with just #2400 included. This has all been delayed in general due to changing work conditions.)

Regarding question 2, if you write your utility.js as an ES module with exports, you can switch from using importScripts() and instead write something that consumes the module exports, and gets compiled into a single final swDest file by webpack:

// In your src/utility.js:

export default {
  myFirstFunction: () => {...},
  mySecondFunction: () => {...},
};

// In your swSrc:

import idbUtils from 'src/utility.js';

// Do something with idbUtils.myFirstFunction(), etc.

This works exactly the same as consuming the Workbox runtime modules works in v5.

[jeffposnick]

(Also, before #2400 ships, you should be able to put your environment variables into a dedicated chunk that is compiled by the main webpack compilation, and then consume that chunk in your swSrc file via the same mechanism that you would refer to a chunk into any other source file that's compiled by webpack.)

[novaknole]

Hey @jeffposnick , do you have an approximate timeframe for when #2400 will be released as this will determine what solution I will implement now based on whether or not i should wait or not.

Thanks ! ! !

[jeffposnick]

This is now available in the v5.1.1 release: https://github.com/GoogleChrome/workbox/releases/tag/v5.1.1