Comments (5)
Dumb question: if I have Build/ThirdParty, and Build/Workers, why do I also need the ones from Source? Mine seems to be working with just
new CopyPlugin([{
from: path.join(cesiumSource, "Assets"),
to: cesiumTarget + "/Assets",
}, {
from: path.join(cesiumBuild, "ThirdParty"),
to: cesiumTarget + "/ThirdParty",
}, {
from: path.join(cesiumSource, "Widgets"),
to: cesiumTarget + "/Widgets",
}, {
from: path.join(cesiumBuild, "Workers"),
to: cesiumTarget + "/Workers",
}]),
from cesium-webpack-example.
UPDATED: This is a better solution which should scale without issue (it uses the force
option of CopyWebpackPlugin
to force overwriting destination files; in this case, overwrite "non-built" code w/ "built" code). This still has a potential issue in that it leaves (in the bundle) "un-built" source files that have no "built" equivalent (e.g. ./Source/Workers/createTaskProcessorWorker.js
):
new CopyWebpackPlugin([
{from: path.join(paths.cesiumSource, 'Assets'), to: 'Assets'},
{from: path.join(paths.cesiumSource, 'ThirdParty'), to: 'ThirdParty'},
{from: path.join(paths.cesiumSource, 'Widgets'), to: 'Widgets'},
{from: path.join(paths.cesiumSource, 'Workers'), to: 'Workers'},
{from: path.join(paths.cesiumSource, '../Build/Cesium/ThirdParty/Workers'), to: 'ThirdParty/Workers', force: true},
{from: path.join(paths.cesiumSource, '../Build/Cesium/Workers'), to: 'Workers', force: true}
])
ORIGINAL:
Some notes about the pattern ("copy source tree and overwrite with built-source tree") used in the solution:
There may be (future) problems with this solutions. For one, there may be files in the unbuilt/source directory (./Source/ThirdParty/Workers
) that are not in the built directory (./Build/Cesium/ThirdParty/Workers
) which don't belong in the bundle but are included anyway. This doesn't present an issue currently.
However, I tried to do this same "copy source and overwrite with built-source" routine for the Cesium Workers (./Source/Workers
and ./Build/Cesium/Workers
) which results in run-time issues:
new CopyWebpackPlugin([
{from: path.join(paths.cesiumSource, 'Assets'), to: 'Assets'},
{from: path.join(paths.cesiumSource, 'ThirdParty'), to: 'ThirdParty'},
{from: path.join(paths.cesiumSource, 'Widgets'), to: 'Widgets'},
{from: path.join(paths.cesiumSource, 'Workers'), to: 'Workers'}
]),
new CopyWebpackPlugin([
{from: path.join(paths.cesiumSource, '../Build/Cesium/ThirdParty/Workers'), to: 'ThirdParty/Workers'},
{from: path.join(paths.cesiumSource, '../Build/Cesium/Workers'), to: 'Workers'}
])
Uncaught Error: importScripts failed for Workers/createVerticesFromHeightmap at http://localhost:3000/Workers/createVerticesFromHeightmap.js
http://requirejs.org/docs/errors.html#importscripts
at makeError (cesiumWorkerBootstrapper.js:188)
at Function.req.load (cesiumWorkerBootstrapper.js:1967)
at Object.load (cesiumWorkerBootstrapper.js:1690)
at Module.load (cesiumWorkerBootstrapper.js:852)
at Module.fetch (cesiumWorkerBootstrapper.js:842)
at Module.check (cesiumWorkerBootstrapper.js:874)
at Module.enable (cesiumWorkerBootstrapper.js:1188)
at Object.enable (cesiumWorkerBootstrapper.js:1561)
at Module.<anonymous> (cesiumWorkerBootstrapper.js:1173)
at cesiumWorkerBootstrapper.js:153
from cesium-webpack-example.
TL;DR -- After digging, it seems like we only need the ThirdParty/Workers
content (inflate.js
and deflate.js
), which is unchanged between Source
and Build/CesiumUnminified
(Build/Cesium
is a minified/UglifyJS2'd version). If you want full control over this source via Webpack, you should use the original copies from Source
.
It's not clear to me what's going on with the See my later comment for details.Source/ThirdParty/Shaders/FXAA3_11.glsl
file, though. It's imported from Source/Scene/FXAA.js
, but the Build/CesiumUnminified
code seems to lack any reference to this at all. It seems like we'll need to copy/account for this file (or the whole ThirdParty/Shaders
directory) via Webpack.
This should get you everything you need (and [mostly] no more) to use Cesium as a library from Webpack. It uses the Almond-bundled-and-minified Web Worker scripts from the Cesium release, as well as the minified ThirdParty/Worker
scripts (currently only inflate.js
and deflate.js
). It also copies the single OpenGL shader file noted above (from the ThirdParty/Shaders
directory). Update: note, this shader file need not be copied.
new CopyWebpackPlugin([
// copy Cesium's non-JS asets
{from: path.join(paths.cesiumSource, 'Assets'), to: 'Assets'},
// copy Cesium's non-JS widget-bits (CSS, SVG, etc.); NOTE: this copies unnecessary JS files!
{from: path.join(paths.cesiumSource, 'Widgets'), to: 'Widgets'},
{from: path.join(paths.cesiumSource, 'ThirdParty/Shaders'), to: 'ThirdParty/Shaders'},
// copy Cesium's Almond-bundled-and-minified Web Worker scripts (from the "built+minified" release)
{from: path.join(paths.cesiumSource, '../Build/Cesium/Workers'), to: 'Workers'},
// copy Cesium's minified third-party scripts (from the "built+minified" release)
{from: path.join(paths.cesiumSource, '../Build/Cesium/ThirdParty/Workers'), to: 'ThirdParty/Workers'},
])
I think the "non-JS widget-bits" could be sourced from the "built" release directory, or have an additional ignore
option, which would avoid copying JS files. I haven't tested this yet, but I believe it's accurate, as Webpack should be fully-managing the JS for "widget-bits."
// copy Cesium's non-JS widget-bits (from the "built+minified" release, to avoid the JS widget-bits)
{from: path.join(paths.cesiumSource, '../Build/Cesium/Widgets'), to: 'Widgets'},
OR
// copy Cesium's non-JS widget-bits
{from: path.join(paths.cesiumSource, 'Widgets'), to: 'Widgets', ignore: ['*.js']},
I have similar questions. First, we must realize that we're talking about the "raw" Cesium library here, not the Sandcastle or CesiumViewer or anything else. The build script(s) accommodates all of these things, and the concerns are not perfectly clearly separated there-in. The ThirdParty
directory in particular holds code that is mainly used for non-library things.
As I understand, the particular piece we need from the "built" cesium is the Cesium Web Worker scripts (that leverage OpenGL/GPU shaders to accelerate computation) because Web Workers have their own "entry-point." The tutorial assumes you'll be happy using the scripts with the Almond AMD loader, and doesn't consider building them with Webpack run-time. It probably wouldn't be hard to make Webpack provide the module-loading run-time for these Web Worker entry-points too, if someone is interested; at that point, we can entirely ignore the Build
directory and work with "raw" Cesium source (Source
), but there are also non-library files in that ThirdParty
directory (for Sandcastle, CesiumViewer, other non-library things), so making this future-proof is non-trivial.
from cesium-webpack-example.
Dumb question: if I have Build/ThirdParty, and Build/Workers, why do I also need the ones from Source?
It will work with either, but using the pre-built workers will be faster.
It's not clear to me what's going on with the Source/ThirdParty/Shaders/FXAA3_11.glsl file, though. It's imported from Source/Scene/FXAA.js, but the Build/CesiumUnminified code seems to lack any reference to this at all. It seems like we'll need to copy/account for this file (or the whole ThirdParty/Shaders directory) via Webpack.
I'm not sure what's going on here without digging, but the .glsl
files are built to .js
, and the .js
is what's actually imported and used by the library.
I have similar questions. First, we must realize that we're talking about the "raw" Cesium library here, not the Sandcastle or CesiumViewer or anything else. The build script(s) accommodates all of these things, and the concerns are not perfectly clearly separated there-in. The ThirdParty directory in particular holds code that is mainly used for non-library things.
It is possible to copy the entire ThirdParty
library if your app requires it, but they are used by the Apps/
directly provided with the Cesium source code (Sandcastle, the CesiumViewer app). The tutorial was targeted towards app development using the Cesium library as opposed to doing Cesium source code development with webpack.
The tutorial assumes you'll be happy using the scripts with the Almond AMD loader, and doesn't consider building them with Webpack run-time. It probably wouldn't be hard to make webpack provide the module-loading run-time for these Web Worker entry-points too, if someone is interested.
We used the pre-built web workers as the source web worker scripts are not compatible with webpack due to their usage of requireJS. (Also modifying the web worker scripts is fairly niche, and the npm package has them already pre-built.) So the workers scripts themselves will require modification if you would like to build them with webpack.
from cesium-webpack-example.
I'm not sure what's going on here without digging, but the
.glsl
files are built to.js
, and the.js
is what's actually imported and used by the library.
Ahh! I see what's going on now, I was getting confused referencing the Git repository vs the npm registry package. While the repository here on GitHub includes the Cesium releases (Build/
), it doesn't include the in-place transformed GLSL -> JS, and the Build/
directory seems to be for an older release which did not include FXAA3_11
code (hence no reference in the Build/CesiumUnminified
directory). The package in the npm registry has all of the necessary bits.
There's no need to worry about the FXAA3_11
GLSL specially, Webpack will properly pick up the .js
file and include it in the bundle (assuming it's there; so make sure you use the npm registry package, or issue a gulp build
if using the Git repository).
This sources all non-JS from the "built+minified" directory, because we're relying on it anyway (to filter Widgets
to non-JS contents, and to grab the pre-built Web Workers), so might as well go all-in.
new CopyWebpackPlugin([
// copy Cesium's non-JS assets
{from: path.join(paths.cesiumSource, '../Build/Cesium/Assets'), to: 'Assets'},
// copy Cesium's non-JS widget-bits (CSS, SVG, etc.)
{from: path.join(paths.cesiumSource, '../Build/Cesium/Widgets'), to: 'Widgets'},
// copy Cesium's Almond-bundled-and-minified Web Worker scripts
{from: path.join(paths.cesiumSource, '../Build/Cesium/Workers'), to: 'Workers'},
// copy Cesium's minified third-party scripts
{from: path.join(paths.cesiumSource, '../Build/Cesium/ThirdParty/Workers'), to: 'ThirdParty/Workers'},
])
from cesium-webpack-example.
Related Issues (20)
- Include loaders for binary files like glb and wasm HOT 7
- Base url issue HOT 1
- Update for webpack4, latest cesium, and optionally vue.js? HOT 7
- Build is broken on master HOT 7
- webpack 5 example HOT 1
- module rules must have exclude: /node_modules/
- webpack >= v2.0.0 support json by default, so should omit json load configuration in webpack.config.js
- CesiumJS & Webpack Guide HOT 1
- Cesium definitely doesn't work with ES6 !!!
- Images/TimelineIcons.png is not showing
- FYI: Created a Vite example
- how to use the build version of cesium HOT 1
- createWorldTerrain not found in cesium HOT 3
- Cesium 1.110 webpack update HOT 3
- Can this allow me to use the latest version of cesium on nuxt2?
- Update the webpack tutorial with latest changes
- Is CESIUM_BASE_URL even still involved in worker setup and do they still need to be copied around? HOT 2
- Remove external node dependencies HOT 1
- Update TUTORIAL.md for new async API
- Include Node polyfill config HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cesium-webpack-example.