Allow inlined third-party dependencies to be externalized

[petermikitsh]

Stencil version:

 @stencil/core@^1.3.3

I'm submitting a:

[ ] bug report
[X] feature request
[ ] support request => Please do not submit support requests here, use one of these channels: https://stencil-worldwide.herokuapp.com/ or https://forum.ionicframework.com/

Current behavior:

When using a third-party javascript library in a component, it is automatically inlined into the output folder (dist/esm-es5/*).

Expected behavior:

I should be able to externalize dependencies to reduce bundle sizes.

Suppose I'm using my stencil components in a higher-level project that also uses redux. I will end up loading two copies of redux in my application, when I only need one.

Steps to reproduce:

• Create a component with a dependency
• Produce a production build of your stencil component library

[manucorporat]

can you share your package.json?

[arielsalminen]

I've been wondering about this same thing. Is there a correct way to do this currently so that certain dependencies would stay external?

Our use case is following: We use Stencil.js in our design system for components, but in addition to components we have 7 other design system NPM packages as well. One example is icons package which is now used within the components, but also in other Angular and React applications. Right now in Angular/React we end up with 2 copies of the icons package, but there must be a way to solve this somehow I’m thinking.

[manucorporat]

Can you please share your package.json? want to check something :)

[arielsalminen]

@manucorporat here you go. I’ve removed some extra meta data and packages from this that should not matter. The icon package I mentioned (@duetds/icons) is listed in devDependencies now:

{
  "name": "...",
  "module": "lib/index.mjs",
  "es2015": "lib/esm/index.mjs",
  "es2017": "lib/esm/index.mjs",
  "jsnext:main": "lib/esm/index.mjs",
  "main": "lib/index.js",
  "unpkg": "lib/duet/duet.js",
  "types": "lib/types/components.d.ts",
  "collection": "lib/collection/collection-manifest.json",
  "publishConfig": {
    "access": "public"
  },
  "directories": {
    "lib": "lib"
  },
  "files": [
    "lib"
  ],
  "scripts": {
    "test": "stencil test --spec --e2e",
    "build": "stencil build --es5",
    "start": "stencil build --docs-readme --es5 --watch --serve"
  },
  "devDependencies": {
    "@duetds/fonts": "^1.3.1",
    "@duetds/icons": "^2.0.3",
    "@duetds/js-utils": "^1.0.16",
    "@duetds/tokens": "^2.0.4",
    "@stencil/core": "1.7.0",
    "@stencil/sass": "1.1.0",
    "@stencil/utils": "latest",
    "@types/jest": "24.0.18",
    "@types/puppeteer": "^1.20.1",
    "copyfiles": "^2.1.1",
    "http-server": "^0.11.1",
    "jest": "24.8.0",
    "jest-cli": "24.8.0",
    "npm-run-all": "^4.1.5",
    "onchange": "^6.1.0",
    "puppeteer": "1.20.0"
  },
  "dependencies": {
    "body-scroll-lock": "^2.6.4",
    "classnames": "^2.2.6"
  }
}

[manucorporat]

Try making that a “dependency” instead of a devDependency.

Also classnames is not required in stencil.

<div class={{
  class: condition,
  class2: condition2
}}>

[arielsalminen]

@manucorporat Will try that early next week! Also: had no idea you could set classes like that in Stencil. Goes to refactor all the components

[petermikitsh]

@manucorporat My apologies for the delay; here is an example repo: https://github.com/petermikitsh/stencil-dependency-example. I used the component starter since that's what my actual project uses.

You can see redux gets inlined here: https://github.com/petermikitsh/stencil-dependency-example/blob/master/dist/esm/my-component.entry.js#L3-L343

The ideal state would be the option to specify redux (or more generically, any dependency) as externalized (e.g, maintain the import import { createStore } from 'redux';, as is done here), for consumption of my stencil-compiled web components in later bundling steps.

[terodox]

This is a real pain point for my project as well.

In rollup we have an options to specify globals in the output options. This let's us keep the main bundle size smaller and utilize CDNs for commonly available scripts.

Rollup Docs for output.globals

Where I currently work we are heavily utilizing CDNed scripts to share common resources across a few dozen standalone applications, and the lack of this feature is extremely painful.

[johnman]

Is this still an issue?

Ideally I would like to define some imports that are not bundled so that they get pulled in at runtime using something like import maps. https://github.com/WICG/import-maps (I know it isn't a standard yet).

[claviska]

What's the ideal solution here? Would exposing globals be sufficient or would it makes sense to also expose external?

[terodox]

For my purposes - globals is the only thing I need at the moment!

[ionitron-bot]

Thanks for the issue! This issue is being closed due to inactivity. If this is still an issue with the latest version of Stencil, please create a new issue and ensure the template is fully filled out.

Thank you for using Stencil!

[claviska]

I'll look into this more next week.

[rwaskiewicz]

Closing this as a duplicate of #3576. While they're not quite the same, #3576 has a little more information/context for the team