Avoid loading dynamic code out of `node_modules` directly

[eamodio]

In the example code you showed loading the js file by getting its uri directly from the node_modules folder. That should be avoided, as we want extensions to be bundled and not ship their raw node_modules folder. So we should look into alternative ways of loading the library -- importing the js as a module or something along those lines. Though I'm not really thrilled with importing the lib directly into the extension, since it then adds size to the extension rather than just to the webview. So maybe there needs to be a bundle/webpack step or something that adds it in.

[hawkticehurst]

Oh, thank you for this catch! I used the URI method early on to quickly pass the toolkit into the webview and test things out, but obviously forgot to switch back.

The toolkit actually already exports all of the components as separate ES modules on top of exporting a bundled lib toolkit.js file. So at least in terms of importing the library as a bunch of JS modules, we should be good.

But I agree that importing the lib/components directly into the extension feels less than ideal. Could you maybe extrapolate a bit more on what you were thinking with the idea of adding a bundle step that could add it into the webview?

[DragosMiloiuNXP]

I'm running into the same problem. I think that importing toolkit.js from node_modules is a bit awkward. Is there a better way to do this now?

[dzhavat]

What I did in one of my extensions was to manually copy the toolkit.min.js in own folder and use it this way. Not the best but until there's a better way, I'd continue doing that.

[hawkticehurst]

@DragosMiloiuNXP I still haven't had time to tackle this specific issue for vanilla-JavaScript-based extensions. I am currently working on a React-based sample extension that by proxy tackles this issue and should be finished sometime in early January.

With that said, if you're willing to use TypeScript for your webview code, I noted a few weeks ago that @orta (a member of the TypeScript compiler team) created an extension that:

• imports the toolkit within the webview source code itself,
• creates a Webpack config to build the TS webview code into JS, and then
• simply uses the getUri helper function to get a reference the build file (instead of getting a reference to the toolkit package)

I hope that's helpful in the meantime (until proper documentation can be created)!

Also if this doesn't solve your specific needs I would love to hear more about what you're hoping to do.

[DragosMiloiuNXP]

@dzhavat, @hawkticehurst Thank you for the answers.

After giving it some thought I decided to use react. So until January when the sample extension will be available, I have time to rewrite my code to use react.

[atanasster]

@DragosMiloiuNXP , I am already using react with webview-ui-toolkit and doing custom registration while looking forward to the release of the react wrappers.

If you would like to start now with react, take a look at my vscode extension:

• register webview-ui-toolkit: https://github.com/ccontrols/instant-documentation-vscode/blob/82a839357e756ccd48f401a6d51804aa2f5c2da9/src/webview/index.tsx#L10
• define IntrinsicElements types: https://github.com/ccontrols/instant-documentation-vscode/blob/master/src/webview/typings.d.ts
• I am also using directly fast-components for the tree view (or any other components that are not yet available in webview-ui-toolkit), while its on the roadmap: https://github.com/ccontrols/instant-documentation-vscode/blob/master/src/webview/fast-components.ts