@material-ui/private-theming entrypoints not found

[eps1lon]

The package itself seems to be there (no 404): https://ga.jspm.io/npm:@material-ui/private-theming@5.0.0-alpha.33/

But the module entrypoint returns a 404: https://ga.jspm.io/npm:@material-ui/private-theming@5.0.0-alpha.33/index.js.

The file exists in UNPKG: https://unpkg.com/@material-ui/private-theming@5.0.0-alpha.33/index.js

full import-map used

<script type="importmap">
  {
    "imports": {
      "@material-ui/core/Paper": "https://ga.jspm.io/npm:@material-ui/core@5.0.0-alpha.34/Typography/index.js",
      "@material-ui/private-theming/ThemeProvider": "https://ga.jspm.io/npm:@material-ui/private-theming@5.0.0-alpha.33/ThemeProvider/index.js",
      "@babel/runtime/helpers/esm/objectWithoutPropertiesLoose": "https://ga.jspm.io/npm:@babel/runtime@7.14.0/helpers/esm/objectWithoutPropertiesLoose.js",
      "@babel/runtime/helpers/esm/extends": "https://ga.jspm.io/npm:@babel/runtime@7.14.0/helpers/esm/extends.js",
      "clsx": "https://ga.jspm.io/npm:clsx@1.1.1/",
      "@material-ui/system": "https://ga.jspm.io/npm:@material-ui/system@5.0.0-alpha.34/index.js",
      "@material-ui/unstyled": "https://ga.jspm.io/npm:@material-ui/unstyled@5.0.0-alpha.34/index.js",
      "@material-ui/styled-engine": "https://ga.jspm.io/npm:@material-ui/styled-engine@5.0.0-alpha.34/index.js",
      "@material-ui/utils": "https://ga.jspm.io/npm:@material-ui/utils@5.0.0-alpha.33/index.js",
      "@material-ui/private-theming": "https://ga.jspm.io/npm:@material-ui/private-theming@5.0.0-alpha.33/index.js",
      "react/jsx-runtime": "https://ga.jspm.io/npm:react@17.0.2/jsx-runtime.js"
    },
    "scopes": {
      "https://ga.jspm.io/": {
        "object-assign": "https://ga.jspm.io/npm:object-assign@4.1.1/index.js",
        "prop-types": "https://ga.jspm.io/npm:prop-types@15.7.2/index.js",
        "react": "https://ga.jspm.io/npm:react@17.0.2/index.js"
      }
    }
  }
</script>

[guybedford]

Thanks for posting the issue - this should be working now! This was actually a feature that was only supported recently in doing the material ui work in always supporting the module field - we used to ignore it. The invalidation process to clear older package build caches for that is still pending a little further testing, although it is built for all new packages (and this one just missed the cutoff).

Note that if doing published package testing, there is still a few hour delay between publishing and availability on jspm. We're working on cutting this down too but just FYI.

[eps1lon]

Note that if doing published package testing, there is still a few hour delay between publishing and availability on jspm. We're working on cutting this down too but just FYI.

Ultimately the import map will point to a local build so @material-ui/* was just a placeholder for any package using module entrypoints.

The same problem occurs with e.g. clsx:
https://ga.jspm.io/npm:clsx@1.1.1/dist/clsx.m.js vs https://unpkg.com/clsx@1.1.1/dist/clsx.m.js

[guybedford]

@eps1lon yes as mentioned the job to clear build caches for all packages with a "module" field is still pending as it's a big update and so I want to make it along with some other updates as well and ensure comprehensive testing.

In cases where the "module" field is not built, the CJS version will be built into an ES module so it should still work fine though - or were you getting a specific load error for the package when constructing an import map against the converted CommonJS?

I've cleared that one manually again now, but as mentioned it will be a couple of weeks before the next full cache clear on supporting the "module" entry point. Also an easy way to debug this is to check the package.json, where a generated "exports" field is aways present on jspm packages.