Stencil: Side effects import no longer bundled

[ch3rub1]

Stencil version:

 @stencil/[email protected]

I'm submitting a:

[x] bug report
[ ] 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:

Since @stencil/core upgrade from 1.14.0 to 1.15.0, side effects imports are no longer bundled into the final build.
Those import are correctly bundled when running jest unit tests.

Expected behavior:
Side effects imports are included in the final build.

Steps to reproduce:

1. Import a module for it's side effects like dayjs locale.
2. Use imported locales anywhere.
3. Run unit tests --> Pass
4. Build or run devServer --> Locale are not imported and locale default fallback is used.

Related code:

import dayjs from 'dayjs';
import 'dayjs/locale/en-ca';
import 'dayjs/locale/en-gb';
import 'dayjs/locale/fr';
import 'dayjs/locale/fr-ca';

console.log(dayjs().locale('en-ca').locale()); // display 'en' instead of 'en-ca'
console.log(dayjs().locale('en-gb').locale()); // display 'en' instead of 'en-gb'
console.log(dayjs().locale('fr').locale()); // display 'en' instead of 'fr'
console.log(dayjs().locale('fr-ca').locale()); // display 'en' instead of 'fr-ca'

Other information:
Those side-effect imports where correctly bundled with @stencil/[email protected].
We manage to force stencil to import these side-effects bundles by referencing them explicitely :

import dayjs from 'dayjs';
import enCaLocale from 'dayjs/locale/en-ca';
import enGbLocale from 'dayjs/locale/en-gb';
import frLocale from 'dayjs/locale/fr';
import frCaLocale from 'dayjs/locale/fr-ca';

dayjs().locale(enGbLocale)
        .locale(enCaLocale)
        .locale(frLocale)
        .locale(frCaLocale);

console.log(dayjs().locale('en-ca').locale()); // display 'en-ca'
console.log(dayjs().locale('en-gb').locale()); // display 'en-gb'
console.log(dayjs().locale('fr').locale()); // display 'fr'
console.log(dayjs().locale('fr-ca').locale()); // display 'fr-ca'

[denyo]

We encountered something similar when updating to 1.16.0

-    "@stencil/core": "~1.15.0",
+    "@stencil/core": "~1.16.0",

It appears that it works with a regular build done via stencil build but not via stencil build --watch --serve.

Here we receive errors like

Uncaught TypeError: Failed to resolve module specifier "json5". Relative references must start with either "/", "./", or "../".

This also happens with other 3rd party packages like classnames and throttle.
Also these warnings are output by the cli

[stencil] [ WARN  ]  Bundling Warning UNRESOLVED_IMPORT
[stencil]            'classnames' is imported by
[stencil]            ./src/components/layout/content-wrapper/content-wrapper.tsx, but
[stencil]            could not be resolved – treating it as an external dependency

[AThiyagarajan]

Couple of days back, I tried to update the stencil to its latest version in my project.
From "@stencil/core": "1.7.5", to the latest version (Not sure 1.15.0 or 1.16.0)

I do get the same error when I am working with moment library. But then I reverted my upgrade I stayed at where I am now.

[ch3rub1]

Strangely we only observe this behavior when building on Windows. Running build on Ubuntu works fine in our case.

[cwaespi]

We have experienced the same problem with 3rd party dependencies after updating @stencil/core from 1.15.0 to 1.16.0.

[ WARN  ]  Bundling Warning UNRESOLVED_IMPORT
           'lozad' is imported by ./src/components/image/image.tsx, but could not be resolved – treating it as an
           external dependency

[ WARN  ]  Bundling Warning UNRESOLVED_IMPORT
           'date-fns' is imported by ./src/components/date-picker/date-picker.tsx, but could not be resolved – treating
           it as an external dependency

[peterpeterparker]

Same as @cwaespi for me, facing the issue while upgrading from v1.15.0 to v1.16.x with one of my own library build with rollup

[ WARN  ]  Bundling Warning UNRESOLVED_IMPORT
           '@deckdeckgo/utils' is imported by ...

[simonhaenisch]

@realDrCastafolte I think if you write your import statements as "just side-effects" imports, it would work (at least we do that in our app and it works):

import dayjs from 'dayjs';

import 'dayjs/locale/en-ca';
import 'dayjs/locale/en-gb';
import 'dayjs/locale/fr';
import 'dayjs/locale/fr-ca';

If you import them (the locales) with a name but then don't actually use the variable with that name, they do indeed look like unused imports (and maybe they are by definition?). Linters would complain about that and if you used the VS Code action "organize imports", then VS Code would remove those imports because they are unused.

[peterpeterparker]

When it comes to me I do such imports as

import {debounce} from '@deckdeckgo/utils';

And that's my lib bundled with Rollup: https://github.com/deckgo/deckdeckgo/tree/master/utils/utils

Stencil v1.15.0 ok, v1.16.0 nope

[ch3rub1]

@simonhaenisch We indeed imported dayjs locales statements as "just side-effects" imports (our imports were exactly as you write them). But, since [email protected], we had to change and import the locales with a name and use them to force stencil to include the locales into the build. Otherwise, locales are not included and default en locale is used as fallback.
We tested on Windows and Linux and we observed that this issue only occurs on Windows : import dayjs locales statements as "just side-effects" imports works fine on Linux (and therefore in our CI build).
We juste upgraded [email protected] and this issue is still there.

[peterpeterparker]

Here a sample repo to reproduce the problem with Stencil v1.16.2 and socket-io

https://github.com/peterpeterparker/stencil-build

[glenveegee]

It's not a windows only thing. I can confirm it's a mac thing too, at least for 1.16.2. Could this have anything to do with a typescript update and type imports https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-exports

In particular this section:

In conjunction with import type, TypeScript 3.8 also adds a new compiler flag to control what happens with imports that won’t be utilized at runtime: importsNotUsedAsValues. This flag takes 3 different values:

remove: this is today’s behavior of dropping these imports. It’s going to continue to be the default, and is a non-breaking change.
preserve: this preserves all imports whose values are never used. This can cause imports/side-effects to be preserved.
error: this preserves all imports (the same as the preserve option), but will error when a value import is only used as a type. This might be useful if you want to ensure no values are being accidentally imported, but still make side-effect imports explicit.

[reld]

I can confirm this is happening in macOS and Ubuntu (in my case pop!OS).
Oddly enough, when I copy by hand the dependencies from the root node_modules folder (located at the root of the lerna monorepo) to the local node_modules folder inside my components package (e.g. packages/components/node_modules) it works. But this should not be the behaviour.

[simonhaenisch]

We have a file src/helpers/moment.ts to generate a customized moment bundle, containing

import momentTimezone from 'moment-timezone/builds/moment-timezone-with-data-10-year-range';
import 'moment/dist/locale/en-nz'; // tslint:disable-line: no-import-side-effect

const moment = momentTimezone as typeof import('moment-timezone');

moment.locale('en-nz');
moment.tz.setDefault('Pacific/Auckland');

type Moment = moment.Moment;

export { moment, Moment };

This works with Stencil 1.15.0 🤷🏻‍♂️

---

I just upgraded to 1.16.3 and then I get

[ WARN  ]  Bundling Warning UNRESOLVED_IMPORT
           'idb' is imported by
           ./node_modules/@firebase/messaging/dist/index.esm.js, but could
           not be resolved – treating it as an external dependency

[ WARN  ]  Bundling Warning UNRESOLVED_IMPORT
           'ionicons' is imported by
           ./node_modules/@ionic/core/dist/collection/index.js, but could not
           be resolved – treating it as an external dependency

[ WARN  ]  Bundling Warning UNRESOLVED_IMPORT
           'idb' is imported by
           ./node_modules/@firebase/installations/dist/index.esm.js, but
           could not be resolved – treating it as an external dependency

but that's probably not related

[dgonzalezr]

I'm just having the same as @simonhaenisch right now :-/

[glenveegee]

There are more like this coming in since the 1.16 update see https://github.com/ionic-team/stencil/issues/2576#issue-658054161

[glenveegee]

Stencil 1.16.4 fixed the issue of unresolved imports for me

[ch3rub1]

Stencil 1.16.4 fixed our dayjs locales imports issue as well

[reld]

Stencil 1.16.4 fixed our imports issues also.
Thank you very much for the update!!!

[ch3rub1]

Since everyone seems to have resolve their issue by upgrading [email protected] I'm closing this issue 😃

[bitflower]

I have a similiar issue with 1.16.5 importing a lib with a default export that worked for over 1,5 years now. It bundles fine but then in the browser not the default export was imported but the "root" of the module making default a prop of that import: