@szechyjs, as linked above it should be very simple to use index.d.ts. Unfortunately it not so smooth.
I'm starting a new Angular project with
[email protected]
[email protected]
@types/[email protected]
When I run my app (ng serve), I've got the following errors:
Error in ./node_modules/cesium/index.js
module not found: error: can't resolve 'path' in ...
Error in ./node_modules/requirejs/bin/r.js
Module parse failed: unexpected character '#'
If I understand the point, it happened because we should use
import * as Cesium from 'cesium/Build/Cesium/Cesium';
as the main file to start from.
But then I've got strange error on the browser console:
Uncaught Error: Core/Credit missing ThirdParty/xss
It's not seems to be a really problem with the Cesium code, because if I just use declare var Cesium; it work fine.
Long story short, I not understand how to use this d.ts without getting errors and without declare var Cesium;
I've gotten the same issue. Any ideas?
I'm having the same issue.. anyone? This is about the 25th issue I've had trying to get Ol-Cesium to work.. it really shouldn't be this buggy or hard!
I'm having the same issue... any ideas?
Ok, I found a workaround, you have to edit the Cesium.js file where it defines ThirdParty/xss making it try to use define before module.exports:
Before:
if (typeof exports === "object" && typeof module !== "undefined") {
module.exports = f()
} else if (typeof define === "function" && define.amd) {
define('ThirdParty/xss', [], f)
} else {
After:
if (typeof define === "function" && define.amd) {
define('ThirdParty/xss', [], f)
} else if (typeof exports === "object" && typeof module !== "undefined") {
module.exports = f()
} else {
This also happens with ThirdParty/NoSleep, so you'll have to do the same
@mrodal, thanks for the solution.
Consider open issue or pr in cesium so this will be solved without modified a node_module lib.
I did some more research, and the root cause it that those libraries (xss and NoSleep) use umd as the webpack targetLibrary, which exports the library in that way to be compatible with amd, commonjs and if none is found, it exposes the library as a global variable. You can see this here
Changing this file in cesium doesnt look like the best option because its a third party library, when they update it, the same error would appear again. Changing in the library repository to use amd instead of umd would break compatibility, so its not a good option either, the real problem seems to be that we have both "exports" and "define"...
Maybe you can try playing with the module and target options in the tsconfig file (reference here) turning them down to commonjs and es5 or something like that
I see that the xss library was removed in cesium master, so for the next release it will probable also be removed. Then, the only problem left is the NoSleep library
Same issue as @hodbauer with modules :
[email protected]
[email protected]
@types/[email protected]
I've cobbled together a workaround that may be useful until importing just works for Cesium in Angular.
Working github repo with Typescript + Cesium + Angular 6
Basically, since import cesium from 'cesium' doesn't work out-of-the-box yet with Angular, add a triple slash directive to tell TypeScript about the type definition file, then declare var Cesium to tell TS that Cesium is defined elsewhere (e.g. in angular.json), and it's off to the races.
I should note that there are instructions for getting Cesium and Webpack set up using an import, however ng eject is not available for Angular 6, which generates a webpack.config.js for editing.
It may be possible to customize Angular's webpack configuration without ng eject, see here and here.
Most helpful comment
I did some more research, and the root cause it that those libraries (xss and NoSleep) use umd as the webpack targetLibrary, which exports the library in that way to be compatible with amd, commonjs and if none is found, it exposes the library as a global variable. You can see this here
Changing this file in cesium doesnt look like the best option because its a third party library, when they update it, the same error would appear again. Changing in the library repository to use amd instead of umd would break compatibility, so its not a good option either, the real problem seems to be that we have both "exports" and "define"...
Maybe you can try playing with the module and target options in the tsconfig file (reference here) turning them down to commonjs and es5 or something like that
I see that the xss library was removed in cesium master, so for the next release it will probable also be removed. Then, the only problem left is the NoSleep library