jspm expects import paths with file extension. Does'nt like bare imports.

[mediabuff]

jspm expects import paths with file extension. Does'nt like bare imports.

[mediabuff]

Thanks for your patience and answering all my questions. I tried various combinations and not able to proceed. I am not too savvy in this area. I will revisit jspm when there are more fool proof examples and it's ready for semi-novices like me. Web pack with all its's configuration complexities and build cycles made me look for alternative and thus started exploring 'browser importmaps' - but this area is still maturing. I will see how far I can go with 'parcel' - less intimidating than webpack. Thanks for all your help.

[guybedford]

@mediabuff I would suggest you read up on the "exports" field here. It defines the import map pathing scheme to use in the package. For existing npm packages, we also have an overrides repo which supports updating the configured exports for known packages, which can be used to add support with just a few lines configuration. See https://github.com/jspm/overrides/blob/main/overrides.json.

[guybedford]

There may be some things we can do to better support packages without exports field support.

[mediabuff]

Could you please help with a sample package.json ? I have following and it does'nt work, CustomClassNameSetup -> CustomClassNameSetup.js

{
"dependencies": {
"@emotion/react": "^11.10.8",
"@emotion/styled": "^11.10.8",
"@mui/icons-material": "^5.11.16",
"@mui/material": "^5.12.2",
"@reduxjs/toolkit": "^1.9.5",
"framer-motion": "^7.10.3",
"react": "^18.2.0",
"react-dom": "^18.2.0",
"react-redux": "^8.0.5",
"react-router-dom": "^6.11.0",
"react-slick": "^0.29.0",
"slick-carousel": "^1.8.1",
"video.js": "7.21.2",
"videojs-youtube": "^2.6.1",
"vite-tsconfig-paths": "^3.6.0"
},
"devDependencies": {
"@types/react": "^18.2.0",
"@types/react-dom": "^18.2.1",
"@types/react-slick": "^0.23.10",
"@types/video.js": "^7.3.51",
"@vitejs/plugin-react": "^2.2.0",
"typescript": "^4.9.5",
"vite": "^3.2.6"
},

"exports": {
"public/CustomClassNameSetup": {
"import": "public/CustomClassNameSetup.js"
}
}
}

[guybedford]

When you import a package, you can import it:

1. From the outside via its package name, packages with "exports" in their package.json expose only those paths defined in exports. Packages without "exports" expose all files as exact extensions.
2. From the inside of the package itself via relative pathing and exact file extensions import './local.js', or the "imports" field (which uses specifiers like import '#internal')
3. From the inside of the package you can also get a view of the package from the "outside" by using its "own name". This is taken from the package.json "name" field. So if the name was myapp in the package.json you can import myapp/path which would correspond to the "exports" field subpath mapping for ./path in the package. In this way you can load from the inside as if it were an external import.

So when looking at your case of a mapping for public/CustomClassNameSetup, you have to be clear about which of (1), (2), and (3) above you are loading it with, using the appropriate resolution.

[mediabuff]

Thanks for the details. Still confused. My original motivation is use a large code base (with bare specifiers) - same source without any changes under 2 build setups 1) Bundler setup 2) Direct browser import setup. I had assumed I could use the same source code for both. with 2) using the jspm technology. Is it possible ?

Please give guide with the syntax in package.json for 2 components in my app/package - one component purely internal use (but has bare specifiers) and a component ((also has bare specifiers) which is visible to the external world for imports.

1. Internal component eg : public/CustomClassNameSetup (bare specifier) mapping to public/CustomClassNameSetup.js
2. Exported component eg: "/public/App" -> "/public/App.js",

[guybedford]

@mediabuff the bare import pattern of public is not compatible with JSPM.

Instead you could do something like this:

package.json

{
  "imports": {
    "#public/*": "./public/*.js"
  },
  "exports": {
    "./*": "./public/*.js"
  }
}

The above would support import 'pkg/x' resolving to pkg/public/x.js if the package were in node_modules/pkg or resolved as the package called "pkg".

Then internally any of the files could load import '#public/x' and get pkg/public/x.js with extension adding as well.

Note that typically you want to not expose all JS files as importable and decide which are public and which are private.

Alternatively to the above, you can use the package own-name pattern which is probably preferable, although it requires changing the import names from import 'public' to import 'mypkg' or whatever your package name is:

package.json

{
  "name": "myapp",
  "exports": {
    "./*": "./public/*.js"
  }
}

if the above were located in node_modules/myapp then you would be able to support:

• import 'myapp/x' at the base resolving node_modules/myapp/public/x.js
• import 'myapp/x' from any file inside of node_modules/myapp resolving the same thing as well.

Globally renaming public to [myapp] shouldn't be that tricky either and seems the closest to what you want.

[guybedford]

@mediabuff you're very welcome. If you have any further questions feel free to ask anytime.