added removeBundle function.

[alessandroabba]

Added funtion to remove single bundle. Used for dinamically cleanup single component from internal cached list, no longer needed in application, instead of clearing all bundles via reset() function.

[amorey]

Thanks for the PR. Can you explain the use case? The original reset() method was added to make it easier to write unit tests for code that depends on loadjs.

[alessandroabba]

The only use case is that we need to unload some bundles to free up resources and leave some other istantiated. We load lot of bundles dinamically served via API based on the context of the application state, changing the context means the bundle is no longer nedded and should be cleaned up.

[amorey]

Are the internal bundleX state objects taking up too much space? bundleCallbackQueue gets emptied as callbacks get executed, bundleIdCache adds a boolean value for every request and bundleResultCache stores a list containing paths not found for every response.

Are you trying to clear out the internal objects or to remove the scripts themselves from the DOM?

[alessandroabba]

The current implementation throws exception when we try to reload a bundle that don't exists in the DOM but previously loadded. The current solution is to use reset() but then we then need to go fetch all the bundles again.

[amorey]

Can you give me an example of the types of bundles you are trying to load? If the bundleIds aren't meaningful to you, you can leave them out altogether:

loadjs(['/path/to/foo.js', '/path/to/bar.js'], function() {
  // foo.js and bar.js loaded
});

[alessandroabba]

we load js through api, when a script is undefined in dom, but we got 200 it's present in the cache but not in the dom, we then need to clean up the components. Sure we can keep using reset().

[amorey]

Do you need to define a bundle ID for the scripts you're loading? Bundle IDs are only necessary if you want to create more complex dependency trees or if you want to execute a callback independently of the initial script load:

loadjs(['/path/to/foo.js', '/path/to/bar.js'], 'foobar');

loadjs.ready('foobar', function() {
  // foo.js and bar.js loaded
});

If you find yourself re-using bundle IDs then you might be using the feature in a way that it wasn't intended.

[alessandroabba]

If you find yourself re-using bundle IDs then you might be using the feature in a way that it wasn't intended.

I thing i did. No need to manage IDs in my case. The only remaining issue is when a 200ok response correspond to an "undefined" module. But we need to manage it otherwise. Thank you

[amorey]

The only remaining issue is when a 200ok response correspond to an "undefined" module.

Can you explain this in more detail? By "undefined" do you mean a loadjs request without a bundle ID?

[alessandroabba]

I mean an http get with a 200 response, but no content. I our case the problem was the api itself, i will try with an empty js file.

[amorey]

Yes, LoadJS uses dynamic <script> tags to fetch scripts which means you can't inspect the response and determine if there's any content. In order to detect content you will have to use an XMLHttpRequest.

[amorey]

Closing pull request. Let me know if you're still having issues with bundle ids.