It appears a recent change to package.json and the build process causes the dist/calcite/calcite.js file to no longer be generated after running npm run build
We have an app that uses calcite.js as part of our app load in dojo, and are hoping there is some way that this file could still be generated as part of the calcite-components build process.
FYI @MikeTschudi
cc @jcfranco @driskull
It might be related to the changes here from the Stencil 2.0: https://github.com/ionic-team/stencil/blob/master/CHANGELOG.md#dist-packagejson
https://github.com/ionic-team/stencil/blob/master/src/compiler/output-targets/readme.md#output-folder-structure-defaults
Does one of these paths help?
@driskull
according to https://github.com/ionic-team/stencil/blob/master/src/compiler/output-targets/readme.md#output-folder-structure-defaults
there should still be a calcite.js file that is created in dist/calcite/calcite.js (shows as "myapp/myapp.js") in the doc.
there is a calcite.js file built in thewww/build folder but that wont be available to us on an npm install of calcite-components, just the stuff in dist
@cosbyr Is it possible for you to use calcite.esm.js, possibly without the dojo loader? If not, I think we can restore some of the Stencil 1 defaults (namely, buildEs5: "prod").
Yes, we would need to set these in stencil config if we want to support older browsers as they are disabled by default now.
https://github.com/ionic-team/stencil/blob/master/CHANGELOG.md#opt-in-for-ie11-edge-16-18-and-safari-10-builds
buildEs5: true,
extras: {
cssVarsShim: true,
dynamicImportShim: true,
safari10: true,
scriptDataOpts: true,
shadowDomShim: true,
appendChildSlotFix: true,
slotChildNodesFix: true
}
If those are set to true then that file does get put there. So it's really a matter of browser support. Do we want to continue supporting the older browsers? @macandcheese
All of the CC components support IE11 - there are some odd styles here and there but functionally they work. We should make a browser support table with component / browsers as axis and note anything not supported (CAC).
I think we should continue to support IE11 at least through EOL - and perhaps until Online etc. are finally done supporting it, which sounds like it may end up being after next summer. Open to other thoughts @Esri/calcite-components but I don't see the harm. We spent a good amount of time making them work in IE11.
We would need to have the browser support table on the front page / Readme to clearly indicate what DOESN'T work. Then once Online etc. do finally drop that requirement we can go through and remove all the hacky IE things we've done. Thoughts?
The ArcGIS API for JavaScript isn't dropping IE 11 and legacy Edge until 4.18 in December, and the current JSAPI uses Dojo's loader complains with "Uncaught SyntaxError: Cannot use import statement outside a module" when loading calcite.esm.js.
Please let's leave calcite.js in until at least 4.18, when we'll be able to use the new loader.
@driskull @macandcheese Let's take the browser support discussion offline since it's technically not related to this issue. In the meantime, the least we can do is restore the previous v1 output, which always enabled ES5 for production builds. I'll submit a PR for this.