Improved Import Map Generation Error Handling / Diagnostics reporting

[thescientist13]

Overview

Coming out of #1389 and the overall effort of #684 to leverage Node's import.meta.resolve API for locating the location of packages and building up the import map from that, there were some unavoidable issues we ran into that we couldn't really work around. At the risk of suppressing legitimate issues arising from the underlying algorithm, we felt it was prudent to at least log out what is happening and call this out on the website.
https://greenwoodjs.dev/docs/introduction/web-standards/#import-maps

Mitigation(s)

Diagnostics Levels

One thought was to provide more granular on / off controls for logging diagnostics, which while make errors "go away", once set to off, you may forget about it there, install a package later on, then bang your had against the wall wondering why something isn't working, all not realizing there might have been an error emitted the whole time.

However, I think this entire category of problems arising from the limitations and gaps of import.meta.resolve + exports maps could potentially be resolved in NodeJS itself...

import.meta.resolvePackageDir *

There is an open issue in the NodeJS issue tracker that would basically solve this entire classification of edge cases for us, but resolving a package's package.json instead of its entry point.

Not only would this eliminate hoping all package's have "correct" entry point configurations, it would also save Greenwood a lot of work of having to all the work it currently does of trying to find that package.json from the entry point location, including false positives for nested package.json files, and obviously for the cases where import.meta.url doesn't give us an entry point at all.

---

If you are coming from the website docs are an experiencing an error where a package is not working for you as expected client side, please comment below and provide

1. package name
2. error message
3. version of Greenwood