Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Supporting redirected URL for dependency normalization #1754

Closed
billiegoose opened this issue Oct 16, 2017 · 7 comments
Closed

Supporting redirected URL for dependency normalization #1754

billiegoose opened this issue Oct 16, 2017 · 7 comments
Labels
feature

Comments

@billiegoose
Copy link

So this works in the latest version of Chrome, which is freaking awesome:

# index.html
<!DOCTYPE html>
<html>
  <head><title>import demo</title></head>
  <body>
    <script type="module" src="./app.js"></script>
  </body>
</html>
# app.js
import { concat } from 'https://unpkg.com/lodash-es'
console.log('lodash =', concat([1,2,],3,4))

Chrome has no tree-shaking and downloads 300+ dependencies (one for every function exported from lodash)... but it works.

Here is what I have for a SystemJS equivalent:

# index.html
<!DOCTYPE html>
<html>
  <head><title>import demo</title></head>
  <body>
    <script src="https://unpkg.com/systemjs/dist/system.js"></script>
    <script>
      SystemJS.config({
        map: {
          'systemjs-babel-build': 'https://unpkg.com/systemjs-plugin-babel/systemjs-babel-browser'
        },
        transpiler: 'https://unpkg.com/systemjs-plugin-babel'
      })
      SystemJS.import('./app.js')
    </script>
  </body>
</html>
# app.js
import { concat } from 'https://unpkg.com/lodash-es'
console.log('lodash =', concat([1,2,],3,4))

And it has the 302 redirect resolution issue explained in ModuleLoader/es-module-loader#538

At the moment, I'm "solving" this by manually mapping module identifiers to their final URL, which basically means adding a line of config for every deep dependency in my project. (And that became so burdensome I started using the UMD builds of my dependencies instead of their native ES6 source code.) I'm building a client-side IDE so I need to be able to dynamically load npm modules, which is why I'm not just using Webpack or something.

Any idea how I can get around this? Is there a hook where I could mangle the resolving algorithm in SystemJS to use the post-302 location?
@guybedford
Copy link
Member

Ok, so the reason for this is we don't support "catching" redirects in the fetch component of SystemJS.

Supporting this is important for spec alignment so let's aim to get this feature in soon.

Basically we'd need something along the following lines:

  • During fetch, detect a redirect, and return the redirect URL along with the source
  • If using scriptLoad then unfortunately we don't have this information so this would have to be for the fetch mode only.
  • This data can be stored as meta.redirectURL or similar on the load record.
  • When resolving dependencies, we'd need to then use the redirectURL over the standard URL as the parent in normalization.

This should be relatively straightforward to implement, so I will aim to get to this, although it won't be very soon unfortunately.

@guybedford guybedford changed the title Discrepency in 302 behavior between SystemJS and native Chrome loader Supporting redirected URL for dependency normalization Oct 17, 2017
@unional
Copy link
Contributor

unional commented Dec 28, 2017

#1772 needs the same functionality when resolving dependencies. The difference is that the "redirectURL" is returned during the plugin's locate call.

This was referenced Mar 12, 2018
Open
Closed
@guybedford
Copy link
Member

This is still a tricky one to support in SystemJS 2.0. Leaving open, but its nature is a wontfix.

@guybedford
Copy link
Member

(although I'm always open to bright ideas too)

@guybedford
Copy link
Member

It should be possible to support with the translate loader though, just not the script loader.

Removing the wontfix label for the translate loader support.

@guybedford
Copy link
Member

I implemented this in es-module-shims in guybedford/es-module-shims@a811843 and it was pretty straightforward.

The hardest part is just figuring out how to pipe this information in the System loader internals.

@guybedford
Copy link
Member

So it turns out the translate loader is not really being focused on. Given this I think we can go back to the wontfix scenario here.

@guybedford guybedford mentioned this issue May 13, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@billiegoose @guybedford @unional