feat: Compatibility with specifier imports

[pabloerhard]

This PR adds compatibility with specifiers, for example:

module.exports = require('#main-entry-point');

These specifiers are defined inside the package.json file and can reference either a local file or an external module.

The proposed solution works as follows: whenever a require call begins with # (all specifiers must start with #), locates the package.json, extracts the corresponding reference from the imports field, and sets the newUrl with the resolved path, maintains any original process after that.

[jsumners-nr]

Looks reasonable with linting fixed.

[jsumners-nr]

A better check is Object.prototype.toString.call(imports) === '[object Object]'.

[BridgeAR]

@jsumners-nr I am surprised by that suggestion (when I just looked at it, I wanted to recommend to check for typeof and not null). That should be much faster and should suffice for the overall check here, if I am not mistaken. Am I missing something / what would the benefit be for calling toString()?

[pabloerhard]

From what I understand, checking with toString() ensures we don't allow values such as [ ], null or Date, which are also of typeof 'object'

[BridgeAR]

I understand that it would not match these anymore. We just check for the property existence on these objects and they should never have the properties we are looking for. Due to that, I favor the faster check.

[pabloerhard]

I agree, I'll add that into the latest changes.

[jsumners-nr]

@BridgeAR the original check was a coercive check for an Object. Various things, e.g Array, would mistakenly satisfy that check.

[pabloerhard]

@jsumners-nr I reinstated it to the original check after considering that the code only performs operations based on certain properties, which are checked for existence before being used. This allows us to maintain the most efficient check.

[BridgeAR]

Suggested change

	} catch (error) {
	} catch {

Alternatively, we could also just add the cause