Sp-dev-docs: Why was lib removed from webpack resolved modules in SPFx 1.10?

[NickSevens]

Category

• [x] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Question

I've just updated one of our solutions to SPFx 1.10, which caused our webpack build to fail.
Took me a while to figure it out, but apparently the lib folder was removed from webpack's resolve modules.

The current webpack config is:

{
  ...
  resolve: {
    alias: {},
    modules: ["node_modules"]
  },
  ...
}

Whereas in previous versions this was

{
  ...
  resolve: {
    alias: {},
    modules: [
      "node_modules",
      "lib"
    ]
  },
  ...
}

Is there a particular reason this has been changed? If so, this might be worthwhile mentioning in the release notes as well.

Tnx.

PS: We fixed this for our solution using the following in gulpfile.js

build.configureWebpack.mergeConfig({
  additionalConfiguration: generatedConfiguration => {
    generatedConfiguration.resolve.modules.push("lib");

    return generatedConfiguration;
  }
});

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[patmill]

Not sure. Let me dig in. Thanks for the heads up.

[halfnibble]

I think we can safely revert this change. It was done to reduce the scope of our webpack module resolution strategy.

@NickSevens Can you clarify how it broke your webpack build? Does your code contain imports depending on webpack to resolve the lib folder? Or is there something in SPFx itself that is breaking?

[NickSevens]

@halfnibble we have an appSettings.json file in the src/ folder, which is used to easily configure our environment variables during runtime, and change it easily in our release pipeline.
Something like:

{
  "appInsightsKey": "...",
  "azureADAppId": "...",
  "webApiUrl": "..."
}

This is declared as a module with an appSettings.d.ts file as such:

declare interface IAppSettings {
  appInsightsKey: string;
  azureADAppId: string;
  webApiUrl: string;
}

declare module "appSettings" {
  const appSettings: IAppSettings;
  export = appSettings;
}

Which in turn makes it importable in our source files with

import * as appSettings from "appSettings";

This means however that webpack should load the module from the tsc compiled lib folder, and not from node_modules, which now seems to be the only one configured in the resolve config.

[halfnibble]

@NickSevens are you setting "typings": "lib/index.d.ts", in your package.json file?

Can you provide a minimal repro that showcases the problem (before the gulpfile workaround).

[NickSevens]

Sure, @halfnibble
https://github.com/NickSevens/spfx-demo-missing-lib-resolve
Run gulp bundle to see the issue.

[halfnibble]

Thank you so much @NickSevens!

Based on your repro repo, I recommend adding "resolveJsonModule": true to your tsconfig.json file.
In addition, you'll need to import from the actual path, e.g.

import * as appSettings from "../../../appSettings.json";

Ideally, there'd be a way to set a webpack alias so you don't have to type the path, but I don't believe our config settings support that currently.

Having lib/ automatically resolve is convenient, but we've found it can also create difficult to debug issues, such as having a root level .ts file with the same name as a node_module package.

We should definitely mention this change in the docs somewhere because it does change how things work.

[NickSevens]

Okay thanks.
Not that developer friendly unfortunately, but I get the reasoning. :)

Ps: would be nice if spfx would support .env files or something alike for global app configs :)

[spoman007]

@NickSevens @halfnibble
I also have similar requirement to update web api urls based on dev vs production.

Can you suggest any recommended way?
https://spblog.net/post/2018/06/24/Read-and-manipulate-SPFx-configuration-values-in-your-code-like-a-boss

Is this a correct approach?

[NickSevens]

@spoman007 I actually wrote a blog post about an alternative way recently:
https://digitalworkplace365.wordpress.com/2020/03/05/using-env-files-in-sharepoint-framework-development

[msftbot[bot]]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues