GlobalStyles not working

[pandasoli]

Does this package have any dependence?

I tried so mucho things, help me pls

[cristianbote]

I'll have to look deeper on how deno resolves the nested packages.

[frenetic43]

I was just looking into deno package resolution.

	Node.js	Deno / ESM Spec
File Extensions	importing without file extensions (a hallmark of commonjs) IE: goober	requires file extension in import paths—because the browser wouldn't be expected to guess. IE: goober.js
import paths	Allows bare-specifiers IE: goober; the node package manager handles absolute URLs transparently	requires absolute or relative paths to an import—again, a browser isn't going to guess IE: https://deno.land/x/goober@v2.1.13/ May allow omission of the filename if an obvious entry point exists, just like index.html can be omitted from a web address

Rules of thumb (for deno)

• Include the file-extension
• Use relative import paths for local files; which you're probably already doing...
  • IE: ./goober.js or ../goober.js
  • Which could be potentially problematic if the module is being imported into a website using a base url tag. I'm not sure.
• Use absolute paths for external resources; which you're probably not doing...
  • This is where we run into some trouble since both deno and node use different package management.
  • Node uses bare specifiers to pre-download modules directly from npm
  • Deno uses qualified URLs to cache a copy of a remote resource at runtime
  • The two local cache and path management systems... do not equate.

---

Fortunately, this isn't really an issue. Or more specifically, it's a question of whether or not the end-user is importing the development source-code (itself containing external imports that may not resolve) or the bundled production single-file module (with the minified code that includes a copy of all dependencies).

Which is what's happening in the example by the original post:

/* https://deno.land/x/goober@v2.1.10/global/src/index.js */   // Importing raw source file
import { css, styled } from 'goober';    // The node bare-specifier 'goober' can't be resolved by deno

/* https://deno.land/x/goober@v2.1.10/global/package.json */
{
  "devDependencies": {
    "goober": "^2.0.29",   // Here is how Node is resolving it.
  }
}

If the user is looking to use the (unminified) source code remotely then deno.land may (or may not) be the best choice depending on how the module is built.

/* import from https://deno.land/x/goober@v2.1.13/global/global.d.ts */
import { Properties as CSSProperties } from 'csstype';
import { Theme, DefaultTheme } from 'goober';

/* import from https://esm.sh/goober@2.1.10/global/global.d.ts */
import { Properties as CSSProperties } from 'https://esm.sh/v135/csstype@3.1.3/index.d.ts';
import { Theme, DefaultTheme } from 'https://esm.sh/v135/goober@2.1.10/goober.d.ts';

Notice how the esm.sh copy has over-written the imports as absolute links back to esm.sh. This will work.

If the end-user is looking to use the unminified source code at all however, they should reasonably just clone the repository and have a local copy. I'm using a local copy of goober myself for server-side-rendering on Deno. Although, I did have to quickly update all the import statements to include file-extensions to get it to work.

But if the end-user is looking to just use goober in production, they should be using a minified version:

https://esm.sh/goober@2.1.13/
https://esm.sh/goober@2.1.13/global

https://unpkg.com/goober@2.1.10?module
// Couldn't find the unpkg goober/global

npm:goober@2.1.10 // Deno also supports the npm prefix to import from, guess where?
// Couldn't find the npm goober/global entry

These are all self-contained minified versions, no trouble using them in deno at all.
Well, aside from the issue I just opened #573.

At some point, I'm assuming deno.land will figure out some standardized entry point so we don't have to keep digging through code to find which file to import, but at the moment it's hit-or-miss.

At the very least, any developers releasing content on deno should list the full URL to their modules in the documentation. But it'll be a while before that becomes a convention, I expect.