Can not import widgets.css file not exported from package.json

[3DGISKing]

I am working on https://github.com/CesiumGS/cesium-webpack-example.
This is very simple web pack configured web app.

It works well with webpack 4(original version).
But after I update web pack version, it shows following error.

Module not found: Error: Package path ./Build/Cesium/Widgets/widgets.css is not exported from package E:\MyResearch\CesiumJsGIS\node_modules\cesium (see exports fiel
d in E:\MyResearch\CesiumJsGIS\node_modules\cesium\package.json)

In a short I could not import css file from node_module.

hope you export widgets.css in package.json.

[bampakoa]

Hey @3DGISKing I think it would make sense to file an issue to the cesium-webpack-example repository instead 😉

[3DGISKing]

this is actually related with this repo.

[bampakoa]

@3DGISKing I am not sure if it is indeed related to this repo, (it may have to do with the webpack configuration) but I think that reporting it there would be a good start for filing the issue 😃 . However, either way, looks valid to me 👍

[3DGISKing]

please have a look at this.

webpack/webpack#11787

[bampakoa]

@3DGISKing i do not know if it is ok to export CSS files through package.json, the maintainers of Cesium can tell that, but you have always the option of the copy-webpack-plugin

[TJKoury]

Try C137.js, webpack example here

[dzungpng]

Closing this issue as we have not received a response from the author in a while. Please re-open if there is additional discussion to be made.

[thw0rted]

Please re-open this issue.

I've never had to set up the exports field in a package.json before but apparently it's a pretty big deal and can break a lot of things, especially now that Webpack 5 fully respects it. I'm going by the webpack docs which refer to the node docs here. (cc @kring because he created the current version )

Once you create an exports field, it has to contain an entry for anything you might ever want to import from the package:

Warning: Introducing the "exports" field prevents consumers of a package from using any entry points that are not defined

This includes if your consumer's build tools need to grab stylesheets (as in the OP), images, JSON data, web workers, anything like that. I haven't spent a lot of time with it but I think at a minimum it should have entries for assets: "./Build/Assets/" and widgets: "./Build/Widgets/". The team might have some ideas about other things "export" explicitly.

[kring]

Is it possible to add some sort of wildcard export that allows any file in CesiumJS to be imported if desired?

[thw0rted]

I've been playing with this for the last half-hour or so. I think this might cover everybody:

  "exports": {
    "./package.json": "./package.json",
    "./Assets/": "./Build/Cesium/Assets/",
    "./ThirdParty/": "./Build/Cesium/ThirdParty/",
    "./Widgets/": "./Build/Cesium/Widgets/",
    "./Workers/": "./Build/Cesium/Workers/",
    ".": {
      "require": "./index.cjs",
      "import": "./Source/Cesium.js"
    }
  },

but you could also use "./": "./" as a fallback, I think. I don't know whether it's better to just expose every file in the package, or carefully consider what you want to expose as the public API of the package. Pros and cons on both sides, I guess.

Also note, though -- Node has deprecated "subpath folder mappings" (like "./path/") in favor of "subpath patterns" (like "./path/*") but webpack doesn't support that yet.

[kring]

Hmm interesting. Some apps import Cesium source files directly, too. i.e. right from the Source directory, not from Build. Maybe we just need to add a ./Source/ export to cover that case as well?

[thw0rted]

This is a tricky question. The package file format has evolved over a relatively long time, which means now you're supporting CJS imports via the main field, older ESM imports using module, and newer consumers from recent Node or Webpack 5+ using exports. I think anybody using the exports field should be able to support ESM modules, though they might mix in require() as well, see the dual package hazard section in the Node docs.

If I'm right, it would mean that consumers using import should always get scripts out of Source, because that's the ESM format they want, so exports should only provide code out of ./Source/. (That's only about code, though. The entries I proposed above are all assets -- JSON data, images, CSS -- so getting the possibly-minified version of the asset out of Build makes sense.)

While we're thinking about this: have you considered distributing a processed/minified version of ES modules instead of Source? Using a structure like that, you could expose individual modules for import like this:

  "exports": {
    "./package.json": "./package.json",
    "./Assets/": "./Build/Cesium/Assets/",
    "./Workers/": "./Build/Cesium/Workers/",
    "./": "./Build/esm/",
    ".": {
      "require": "./index.cjs",
      "import": "./Build/esm/Cesium.js"
    }
  },

This would let consumers write import Viewer from "cesium/Widgets/Viewer" and get a tree-shakable minified ESM version of Viewer (and its dependencies).

[TJKoury]

For what it is worth I agree with @thw0rted above, that config works, and the proposal of distributing a minified version of each ES module is exactly what is needed.

Just for kicks I upgraded my example with c137.js here to Webpack 5 and it still works without a hitch.

[thw0rted]

Another interesting finding came up just now. Your ./index.cjs is basically a conditional redirect to give CJS consumers a minified build in a production environment or an unminified build otherwise. In Webpack, you have access to conditional matchers for production and development. I believe that means you can use

    ".": {
      "production": {
        "require": "./Build/Cesium/Cesium.js",
        "import": "./Source/Cesium.js"
      },
      "development": {
        "require": "./Build/CesiumUnminified/Cesium.js",
        "import": "./Source/Cesium.js"
      },
      "node": {
        "require": "./index.cjs",
        "import": "./Source/Cesium.js"
      }
    }
  },

This is good because it cuts out a runtime decision (i.e. the return value of path.join(...) in index.cjs), which is bad for webpack's require because it's forced to create a context for dynamic resolution. (TBH I think it's unusual for a package to provide different code based on NODE_ENV but in my above example you could preserve this behavior, if you like.)