backstage: Bug prevents rendering in Safari

My fix is to add

  "resolutions": {
    "**/parse-url": "5.0.0",
    "**/git-up": "4.0.2"
  }

To the top level package.json

FYI: the issue https://github.com/IonicaBizau/parse-url/issues/32 was closed and a new parse-url version was released (8.0.0) with a bump "normalize-url": "^7.0.3" and a fix for the esm errors. The regex fix is on the way https://github.com/privatenumber/parse-url/pull/1

Update - i got a fix merged and released to remove the safari-breaking regex. Only to discover that they exclusively dist as ESM now which our dependency isn’t set up to consume, being purely CJS and not having a build/transpile setup.

So uh, that’s where we are right now. Not sure how to best proceed.

This definitely is still an existing issue and should not be closed.

Asking partially to try to prevent this from closing, but would be nice if this one stayed open at least so people can discover the workaround with the pinned resolution.

I wanted to update this issue as this is the goto based on the other closed issues. We see the same issue as reported in https://github.com/backstage/backstage/issues/8515#issuecomment-997915113 when pinning normalize-url to 7.0.1.

The frontend can load, but the backend cannot start.

/Users/bjornhaldsorensen/lunar/lunar-backstage/packages/backend/dist/main.js:598
/******/ 			throw e;
         			^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /Users/bjornhaldsorensen/lunar/lunar-backstage/node_modules/normalize-url/index.js
require() of ES modules is not supported.
require() of /Users/bjornhaldsorensen/lunar/lunar-backstage/node_modules/normalize-url/index.js from /Users/bjornhaldsorensen/lunar/lunar-backstage/node_modules/parse-url/lib/index.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename /Users/bjornhaldsorensen/lunar/lunar-backstage/node_modules/normalize-url/index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /Users/bjornhaldsorensen/lunar/lunar-backstage/node_modules/normalize-url/package.json.

    at new NodeError (internal/errors.js:322:7)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1102:13)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:12)
    at Module.require (internal/modules/cjs/loader.js:974:19)
    at require (internal/modules/cjs/helpers.js:93:18)
    at Object.<anonymous> (/Users/bjornhaldsorensen/lunar/lunar-backstage/node_modules/parse-url/lib/index.js:6:20)
    at Module._compile (internal/modules/cjs/loader.js:1085:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
    at Module.load (internal/modules/cjs/loader.js:950:32) {
  code: 'ERR_REQUIRE_ESM'
}

I have worked around it by pinning parse-url to 5.0.0 instead.

I’ve raised the above PR to bump all plugins in this repo, but any other plugins will also need bumping if they depend on it directly, or depend on some of our packages with an outdated version too 🙏

Hi. Would it be possible to detect Safari and return a simple text document with ‘Please switch to xxx’? This would avoid wasting time when this problem is re-discovered.

Yes, and that concern is what I mean you should bring up with the upstream library, that this is still broken in the later versions. It’s not something that we control, so we should track this issue upstream to get if fixed, and then we can push out the version bump here.

@jhaals upon further inspection it looks like we’re still waiting for https://github.com/privatenumber/parse-url/pull/1 to make it to upstream. And then it should be ready I believe?

Interesting that if they’re not going to backport the fix to packages without esm support we might need to wait for this: #12218 also

The resolutions put forward by agates4 work for us - but parse-url@v^5.0.0 contains a critical security vulnerability.

When bumping the package version to either the latest (7.0.2) or to ^6.0.1, where the vulnerability was patched, the Safari bug reoccurs.

Posting for visibility - the package resolution that fixed this issue for us is not secure.

@mmonroe-vmware Would you have the ability to check if latest master still exhibits this problem on safari, after this change? https://github.com/backstage/backstage/pull/12397

Based off of the possible solution given, I used:

  "resolutions": {
    "**/git-up": "4.0.2"
  },

in my top level package.json and that has worked around the issue for me until something better comes along, doing it at the parse-url package level gave a warning so I went with git-up. In case it’s useful for other passers-by.