Encourage Explicit Import Paths for Better Compatibility and Predictability

[jimmywarting]

Title:

Description:
When using Alpine.js via a CDN (e.g., jsDelivr), importing modules without explicit file extensions may lead to issues. For example, attempting to import the CSP build results in a 404 error:

import Alpine from 'https://cdn.jsdelivr.net/npm/@alpinejs/csp@3.14.9/builds/cdn.js';

This error occurs because Alpine.js includes module imports without explicitly specifying file extensions. Some runtime environments and CDNs, including Deno, enforce stricter module resolution and do not guess the correct extension.

Example Error:

GET https://cdn.jsdelivr.net/npm/@alpinejs/csp@3.14.9/src/index net::ERR_ABORTED 404 (Not Found)

Suggested Solution:

• Explicitly specify .js in all import paths, e.g.: javascript import Alpine from './index.js';
• This approach is aligned with best practices and ensures compatibility across multiple environments.

Ryan dhal did regreted the hole module resolver thinking index was cute, but oh so wrong he was. it adds complexity to a simple solution that don't even work in the browser/esm. It gets harder to make the switch by refactoring code to esm. paths need to be guessed/looked up: did you meant to import foo.js or foo/index.js? Remote path resolver don't have this luxury where it dose not have direct access to the harddrive and can't lookup the file that is needed.

[SimoTod]

I know it's not the point of the issue but you should use a cdn to build your own bundle. Deno supports npm and I suspect it will be okay if you pull your file locally.

If it's for code running in the browser, you shouldn't use the source code but the file in the dist folder.

[jimmywarting]

Either way, you should start using explicit path anyway. Building a own bundler or stuff like it makes it just more complicated.

I wanted to use the original source code for development purpose (easier to debug)

[SimoTod]

Yeah so what I meant is that you can check out the code locally via npm, you don't want to use a remote source file from a cdn (the uncompiled code shouldn't even be available from the cdn, imo).

P.s. I'm down as a collaborator because I helped with a feature in the past but I'm not really any decisional power for the project.
In general, PRs with a lot of changed files, little context and no tangible benefits/differences (for the maintainer) have a hard time to get reviewed and merged into the project.