3

This is specifically focusing on Salesforce specific Lightning Web Components and not Open Source Lightning Web Components. Now I understand the process of uploading the 3rd Party Library as a Static Resource and that the modules can't be imported directly, but I wanted to see if there were any benefits or drawbacks by importing the 3rd party library into the package.json.

The benefit I'm looking to get is that we have security analysis tools currently running over the source code repository, so by including the 3rd party library in the package.json, the security tool can flag any vulnerabilities with the 3rd party library and we can update the static resource.

Are there any other benefits or drawbacks from taking this approach?

Improve this question

2 Answers 2

Reset to default
4

It does not hurt to have your libraries in package.json and have package.json stored in your github repository for the project or even in the static resource.

Although as a best practice I recommend you have separate folder in your project where you keep your JavaScript source including third party and then use a bundler like webpack and build a minified Javascript that you store in static resource. (If you are using a continuous integration you can automate all this )

LWC can then only import minified JavaScript and will be faster load because of the size of the script.

Improve this answer
1
  • I'll wait to see if anyone has any other answers before accepting to contribute but overall this makes great sense. It's sometimes good to have these things in writing around architectural design approaches as the bundler approach for static resources is an awesome idea.
    – Clint
    Commented Jul 29, 2019 at 1:53
1

You are referring to completely 2 different flows:

  1. Getting/saving 3rd party library in salesforce org.
  2. Referring to that library either by importing module or by static resource.

You can choose to run static code analysis when the library is in static resource of in a module. More specifically the benefits or drawbacks are boiled down to how you are referring to the library which is very well explained in Import ES modules in LWC.

So, according to it, it is actually beneficial by referring to static resource (as you said by package.json)

--added--

According to documentation,

When using these libraries in a Lightning web component, add lwc:dom="manual" to any HTML element that you want to manipulate with JavaScript. When the engine sees the directive, it preserves encapsulation.

LWC encapsulates that block where 3rd party library wants to manipulate DOM, by using lwc:dom. Now, 3rd party library has full control over that region of component. So, it is very good idea to include it for running security checks on it. There will be no disadvantages as you said security tool acts on source code (only deployment may get a little longer) directly and will not interfere with code in regular transactions.

Improve this answer
1
  • 1
    Sorry but you've misinterpreted my question or I haven't explained myself clearly enough. I get the concept of using 3rd party libraries with LWC. My question is focusing on if there are negative effects including it in a package.json build. I would not want to analyse the raw library with a static code analysis tool via a static resource as that's an unnecessary overhead. A lot of the security tools will check a package.json file library vulnerabilities which is what my question is getting at.
    – Clint
    Commented Jul 28, 2019 at 10:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .