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.

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

Embedding System.js into bundle #3624

Open
TeoTN opened this issue Jun 8, 2020 · 14 comments
Open

Embedding System.js into bundle #3624

TeoTN opened this issue Jun 8, 2020 · 14 comments

Comments

@TeoTN
Copy link

TeoTN commented Jun 8, 2020

Feature Use Case

Bundles where single JS entrypoint is allowed that have to support IE

Feature Proposal

Would it be possible to enable embedding system.js in the output bundle? I'd like to have a single entry point with system.js that would be able to load more code using system js imports format. At the moment we need to include system.js separately.

@shellscape
Copy link
Contributor

This looks a lot like a support request rather than a feature request. Would you be able to flesh this out some more before the maintainers tackle this one please?

@TeoTN
Copy link
Author

TeoTN commented Jun 10, 2020

It's not a support request really? Currently, one can set the output format to be systemjs (or amd, or other) but onus is on the user to embed systemjs separately. It'd be nice if rollup config had an option to embed the system.js (and amd respectively) runner into the bundle (the main file in case of code splitting).

@frank-dspeed
Copy link
Contributor

@TeoTN there are tons of ways to archive that. The most easy that i can guess of at present is setting a banner for the entrypoint and that banner is simply the SystemJS Code to load it.
and in the footer, you close that.

@TeoTN
Copy link
Author

TeoTN commented Jul 14, 2020

@frank-dspeed It doesn't seem to be well suited for that, and it doesn't work (throwing errors). The banner is a static string, so I'd have to copy paste the entire bundle of system.js there, or read the file and inject.
And if I used a plugin like rollup-plugin-banner, then rollup would split that into a separate chunk, that can't be loaded because... well, the chunk contains what is needed to run those chunks.

@frank-dspeed
Copy link
Contributor

@TeoTN there are tons of ideas as sayed maybe you find a better one

The final solution that always works is the programatical way.

look into direktspeed/plugins#1 and there you can see how the code gets used for hasing so there you can also add your stuff. And even join chunks.

@TeoTN
Copy link
Author

TeoTN commented Jul 14, 2020

@frank-dspeed could you please mention some options that would allow that, that are not writing a plugin from scratch? I'd be happy to try them out.

Given that rollup supports systemjs and amd out of the box, it'd probably make sense to allow also embedding the runner into the bundle easily. Webpack, for instance, embeds a runtime that does the thing for you. Probably allowing to opt in to some runner would be a lean alternative to that feature, while maintaining some convenience.

@lukastaegert
Copy link
Member

I remember that I actually looked into this in the past and my finding was that in contrast to AMD, the SystemJS runtime just does not support this at the moment. The problem is how to load the first chunk as apparently SystemJS always expects chunks to correspond to individual files. AMD on the other hand supports ids where you can manually add an id to the registry and at the same time load it as the first chunk (or there is even a short-cut where you immediately execute a chunk in RequireJS, I do not recall at the moment). For AMD I can tell you there is already a fully baked solution https://github.com/surma/rollup-plugin-off-main-thread that injects a custom AMD loader into your entry chunk. Bonus is that it allows code-sharing with workers.

@lukastaegert
Copy link
Member

However as I said, it was some time ago I tried this. Maybe @guybedford has something to add here with regard to SystemJS, is it technically possible to inject the loader into the entry chunk?

@frank-dspeed
Copy link
Contributor

@lukastaegert it must be possible there is a really good bundler and loader around with the name StealJS is uses rollup and traceur under the hood to get es6 running while transpiling to compatible code it is bases on SystemJS as a loader and as module formart and it gets embeded inside the bundels.

https://stealjs.com

it is the best bundler if you target IE6 and older stuff it solves everything. While rollup is more modern.

But in case of compatibility there is no better around.

@TeoTN
Copy link
Author

TeoTN commented Jul 15, 2020

@frank-dspeed thank for your suggestion but migrating to a fairly unpopular bundler with 1k weekly downloads is not an option for my team.

I'll be waiting for further information if injecting easily the SystemJS loader into the bundle would be possible, that would save me a lot of problems.

Thanks!

@frank-dspeed
Copy link
Contributor

@TeoTN you could inspect that project to look how it works
why should we do the work?

@frank-dspeed
Copy link
Contributor

i found out it is as easy as loading systemjs then the system.register calls do the rest

@TeoTN
Copy link
Author

TeoTN commented Jul 15, 2020

@frank-dspeed that was pretty aggressive. I think I don't want anything from you, really.
I've suggested that there's a feature that would be useful that webpack has and maybe others would benefit from that as well.

You're just throwing vague statements that there's tons of ways to do this, but you failed to provide any examples. I'm not willing to dive into source code of some random libraries or write my own plugin for that, basically because rewriting my config to webpack would be faster and requires less mental effort.

I didn't know that suggesting features is unwelcome.

@rollup rollup locked as too heated and limited conversation to collaborators Jul 15, 2020
@shellscape
Copy link
Contributor

Hey @TeoTN sorry for locking this one, but after seeing the last few comments I thought everyone would benefit from a quick pause on this issue to take a breath. We're certainly interested in your use case and in improving Rollup. When we come back to this one, let's reset there and look at what possible workarounds there might be that don't involve adding code to Rollup, to start. From there we can look again into what it would take for Rollup to support this directly if there aren't any good workarounds. We might even be able to leverage a plugin for this.

@frank-dspeed please take a moment to consider @TeoTN comment about your reply:

@TeoTN you could inspect that project to look how it works
why should we do the work?

While I understand where you're coming from having worked with you some in the past, other users aren't going to share that perspective and it's reasonable to say that your reply was too terse and could be misconstrued as aggressive.

Let's regroup in a day or so 🎉

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants