Update default provider to use jspm.io instead of jspm

[josefarias]

Coming from basecamp/local_time#113 (comment)

I realized the HTTP request in Importmap::Packager#import was returning HTTP401:

Code:
401

Body:
{"error":"Error: No provider named \"jspm\" has been defined."}

This matches the behavior of a test that's currently failing:

❯ bin/test test/packager_integration_test.rb

Error:
Importmap::PackagerIntegrationTest#test_successful_import_against_live_service:
NoMethodError: undefined method `[]' for nil:NilClass
    /Users/jose/my_repos/importmap-rails/test/packager_integration_test.rb:8:in `block in <class:PackagerIntegrationTest>'


bin/test /Users/jose/my_repos/importmap-rails/test/packager_integration_test.rb:7

This happens because Importmap::Packager#import returns nil when the HTTP response is 401:

importmap-rails/lib/importmap/packager.rb

Lines 28 to 32 in be74dea

	case response.code
	when "200" then extract_parsed_imports(response)
	when "404", "401" then nil
	else handle_failure_response(response)
	end

Per https://jspm.org/cdn/api#download, the accepted provider options are jspm.io | jsdelivr | unpkg — So the fix should be as simple as using jspm.io instead of jspm.

All tests pass after this change.

Possibly related: jspm/generator#274

[guybedford]

To chime in here - we updated the main API service for JSPM to the Generator 2.0.0 version last night, which looks like it caused this break. I've just re-added a backwards compat fix here to the API service and deployed that so the test should now again be passing and this PR should no longer be necessary - but it can still be landed since we are exactly using jspm.io as the primary provider name.

[josefarias]

To chime in here - we updated the main API service for JSPM to the Generator 2.0.0 version last night, which looks like it caused this break. I've just re-added a backwards compat fix here to the API service and deployed that so the test should now again be passing and this PR should no longer be necessary - but it can still be landed since we are exactly using jspm.io as the primary provider name.

Thanks for the context and quick fix @guybedford. Happy to either move forward or drop this PR. I'll leave it up to the maintainers.

Can confirm things work now without this change per my own local tests.

[dhh]

@guybedford If you plan to keep the alias, I'd prefer not to merge this, as "jspm.io" is a bit of an awkward CLI parameter compared to just "jspm". But don't want this to break going forward!

[josefarias]

@dhh could also do something like 486c5d1

But agree we don't need to be overly defensive if the alias is being kept long term.

[guybedford]

In the generator and JSPM CLI itself we only now support jspm.io as the provider value, but for the JSPM API I'm happy to continue to support the alias going forward.

[dhh]

Might as well go with your primary name, then. But thanks for maintaining the alias until people have upgraded 🙏