Billboard.js: Question: "d3-scale" not compatible with IE11

Created on 7 Apr 2020  路  5Comments  路  Source: naver/billboard.js

Description

Hello @netil,
Is there any special reason for using "d3-scale" version 3?
In https://github.com/naver/billboard.js/commit/fc5210b379078dcef11b46c209f0313f30a21c9a you splitted the d3 dependecies into separate modules and you directly use "d3-scale" version 3.0.1, which is incompatilbe with pre-ES2015 environments as written in the release notes of "d3-scale" version 3.0.0:

Note: this release adopts ES2015 language features such as for-of and drops support for older browsers, including IE. If you need to support pre-ES2015 environments, you should stick with d3-scale 2.x or use a transpiler.

I know, that there is special packaged billboard version for IE use, but this is not an option for our use case.
Transpiling d3-modules is also not possible in our use case.

As for now, billboard is using all recoomended dependencies versions for being compatible with older browsers, apart from "d3-array" and "d3-scale".
D3 recommends to use "d3-scale" version 2 to be compatible with older browser without using the packaged version.

I tested billboard on my local build with "d3-scale" version 2.2.2 and it all tests are passing. I haven't checked more, but it seems to not break anything with downgrading "d3-scale" to version 2.

Is there any possibility to downgrade "d3-scale" to version 2 to improve billboard compatibility with older browsers?

question released suggestion

Most helpful comment

@michkami, understood and thanks for sharing infos.

The current modules where can arise issues are, d3-scale and d3-array. d3-array is used only from the Stanford plugin and mainly the used functionality can be replaced using vanilla code, so isn't a big deal handling d3-array.

I'm seeing the downgrade of d3-scale to v2.x will facilitate for general use cases.
I'll be fixing this and release as patch version.

All 5 comments

Is there any special reason for using "d3-scale" version 3?

Well, keeping all the dependencies up to date is the basic approach to maintain the project safe from possible bugs, beneficial from the improvements, the use of new features, etc.

I wrote a guide exactly for this issue. If you haven't read recommend to read it first, but according your mentions, you already tried the solutions, right?

I know, that there is special packaged billboard version for IE use, but this is not an option for our use case.
Transpiling d3-modules is also not possible in our use case.

Can you give more details about this? Because if there're cases where can't transpile nor use the packaged build, it needs to consider downgrade d3-scale.

I wrote a guide exactly for this issue. If you haven't read recommend to read it first, but according your mentions, you already tried the solutions, right?

Yes, I tried the solutions, but as I said, it's not working for us because of 3 main reasons:

  1. We are using the Angular CLI without webpack config for building (transpiling not possible).

    • Adding webpack config to our project requires bigger changes to the structure of the project and the build process, what we want to avoid.

  2. We can't use the packaged build because:

    • we have some polyfill conflicts (especially promises) with this build

    • we are using the latest D3 Version (5.15.1) for our own graphics

    • the size of our project would increase significantly

  3. We are using the latest D3 Version (5.15.1) for our own graphics.

    • as we must support IE 11 and D3 v5 is fully compatible with Internet Explorer, we have to use the packages used in D3 v5

    • by using the packaged build, we would always have 2 versions of d3 packages

    • as soon as our d3 package versions are different from billboard d3 package versions, we would get conflicts

    • if we drop our d3 dependency and use d3 packages from billboards packaged build, we would get unnecessary dependencies for our own graphics



      • in this case we would have to stop importing d3 as ESM in our own graphics, which we want to avoid because decreasing bundles size


      • in the case we need to use d3 packages not included in the packaged build, we would have to add them manually and import them as ESM, which would make us import d3 in two different ways



Well, keeping all the dependencies up to date is the basic approach to maintain the project safe from possible bugs, beneficial from the improvements, the use of new features, etc.

D3 v5 is compatible with Internet Explorer, that's why it is using "d3-scale" version 2.2.2.
As long as D3 is using it, it should be considered to use the same version to ensure that there are no compatibility problems.

@michkami, understood and thanks for sharing infos.

The current modules where can arise issues are, d3-scale and d3-array. d3-array is used only from the Stanford plugin and mainly the used functionality can be replaced using vanilla code, so isn't a big deal handling d3-array.

I'm seeing the downgrade of d3-scale to v2.x will facilitate for general use cases.
I'll be fixing this and release as patch version.

Thank you @netil for quick response and promised patch :) This will will save us a lot of work.

:tada: This issue has been resolved in version 1.12.3 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

Was this page helpful?
0 / 5 - 0 ratings